Thanks for the suggestion! We are considering the feature for inclusion in 5.0. However there are lot's of questions about how TeamCity builds and Maven artifacts will align. Hope, we will be able to do initial implementation of the feature in a month or two and you will be able to try EAP build and tell us what improvements it needs.
* Integrated code coverage for .NET projects using the code coverage functionality that comes with Visual Studio team edition (that would have to be installed on the build agents).
* Audit log of all activities that happen on the server
* Being able to restrict who runs a particular build within a configuration for security reasons.
* Lower the barrier to entry to get dependent builds working (this is what Cruise does better than TeamCity in my opinion).
* Better functionality for how an administrator manages agents, with some intelligence for recommending more agents, or more agents with a particular software set.
* Improve the Visual Studio plugin to be at the professional/polished level that Resharper is at.
I'd like to see more votes for two issues I've reported, http://jetbrains.net/tracker/issue2/TW-6334 and especially http://jetbrains.net/tracker/issue2/TW-6377. Our projects build with Ant and Ivy, so the improved Maven integration wouldn't do much for me.
I'd support easier creating of branch builds. Currently one manually has to: 1) copy the VCS-ROOT, rename the branch 2) change the checkout-directory 3) change the build-config name
All this could be a single step (giving the branch name), the other values could be done by definition. It would also be good, when 'creating branch builds' was a seperate admission, as currently I have to give project administrator rights to selected members of each team.
Futhermore tools like PMD, Findbugs and Checkstyle have one big problem: huge failure reports, when you start with a new project. Quality managers typically can't force to resolve all issues, BUT most of the time could perfectly live, when at least it is guaranteed that it doesn't get worse. Teamcity could support this very easily and generically, when there was an option like 'fail build if some of the statistics got worse (compared to the last successfull build).
We will try to put several of the mentioned topics on public discussion to get more details and use cases so that we can make more informed decisions about the features.
It would be nice to see a schedule of all of the builds that use time based triggering. Right now you'd have to drill into each configuration to see when it is scheduled.
E.g. Parent->child relationship. I define a parent build template. All configs i create from that template inherit its defaults. If i change a setting at the top level config, all chidren inherit it.
2) Customizable views
Let me create a portal view and add build configurations to it. Let those build configurations come from any project.
Some pet feature requests: Better source control integration. More specifically, the host/username/password should just be stored once, not once for every project.
The main page gets a bit overloaded - it would be great to have some kind of view/filter on that page.
It would be nice to have the status line on top state what build is running (ie 1 build running : Smurfies :: daily)
And my pet peeve: I really like the snapshot dependency and how the build chain is nicely visible.
However, I use triggered builds a lot. I.e. Library 1 triggers Library 2 and system components 3, 4 and 5.
Web component 1 then depends on library 1 and 2 and all of the system components.
Now, when library 1 gets built, it triggers all of the above projects. Now say that web component 1 is the next one in the queue. It will get built and potentially it will get built over and over again, after each of the other projects.
This could potentially be addressed by one of these solutions:
Allow the user to specify the order of "dependent builds"
Allow the user to specify some kind of "only trigger this if build was triggered by check-in or expicit build request"
Maintain a dependency tree (internally) of what build trigger which build and intelligently manage the build queue
21 comments:
Creation and further maintenance of project hierarchy from Maven pom files.
In result, we will have many little projects, connected to each other with build dependencies.
This will allow to reach significant build speed-up in case of single-module changes.
Pavel,
Thanks for the suggestion! We are considering the feature for inclusion in 5.0. However there are lot's of questions about how TeamCity builds and Maven artifacts will align. Hope, we will be able to do initial implementation of the feature in a month or two and you will be able to try EAP build and tell us what improvements it needs.
More and more votes for http://jetbrains.net/tracker/issue2/TW-5934
The greatest feature new version of TeamCity can have is built-in Maven repository.
Usually I skip EAP versions, but Maven-enabled TeamCity should be delicious.
cheers!
* Integrated code coverage for .NET projects using the code coverage functionality that comes with Visual Studio team edition (that would have to be installed on the build agents).
* Audit log of all activities that happen on the server
* Being able to restrict who runs a particular build within a configuration for security reasons.
* Lower the barrier to entry to get dependent builds working (this is what Cruise does better than TeamCity in my opinion).
* Better functionality for how an administrator manages agents, with some intelligence for recommending more agents, or more agents with a particular software set.
* Improve the Visual Studio plugin to be at the professional/polished level that Resharper is at.
I'd like to see more votes for two issues I've reported, http://jetbrains.net/tracker/issue2/TW-6334 and especially http://jetbrains.net/tracker/issue2/TW-6377. Our projects build with Ant and Ivy, so the improved Maven integration wouldn't do much for me.
Support for automatic detection and setup of CI for new branches would be nice
http://tech.groups.yahoo.com/group/altdotnet/message/21414
I'd support easier creating of branch builds.
Currently one manually has to:
1) copy the VCS-ROOT, rename the branch
2) change the checkout-directory
3) change the build-config name
All this could be a single step (giving the branch name), the other values could be done by definition.
It would also be good, when 'creating branch builds' was a seperate admission, as currently I have to give project administrator rights to selected members of each team.
Futhermore tools like PMD, Findbugs and Checkstyle have one big problem: huge failure reports, when you start with a new project.
Quality managers typically can't force to resolve all issues, BUT most of the time could perfectly live, when at least it is guaranteed that it doesn't get worse.
Teamcity could support this very easily and generically, when there was an option like 'fail build if some of the statistics got worse (compared to the last successfull build).
Thank you for the suggestions!
We will try to put several of the mentioned topics on public discussion to get more details and use cases so that we can make more informed decisions about the features.
In the meantime, feel free to add more!
It would be nice to see a schedule of all of the builds that use time based triggering. Right now you'd have to drill into each configuration to see when it is scheduled.
1) Better management of build configurations!
E.g. Parent->child relationship. I define a parent build template. All configs i create from that template inherit its defaults. If i change a setting at the top level config, all chidren inherit it.
2) Customizable views
Let me create a portal view and add build configurations to it. Let those build configurations come from any project.
http://jetbrains.net/tracker/issue2/TW-5033
and
http://jetbrains.net/tracker/issue2/TW-3350?query=voted+by+ruel+loehr
Some pet feature requests:
Better source control integration. More specifically, the host/username/password should just be stored once, not once for every project.
The main page gets a bit overloaded - it would be great to have some kind of view/filter on that page.
It would be nice to have the status line on top state what build is running (ie 1 build running : Smurfies :: daily)
And my pet peeve: I really like the snapshot dependency and how the build chain is nicely visible.
However, I use triggered builds a lot. I.e. Library 1 triggers Library 2 and system components 3, 4 and 5.
Web component 1 then depends on library 1 and 2 and all of the system components.
Now, when library 1 gets built, it triggers all of the above projects. Now say that web component 1 is the next one in the queue. It will get built and potentially it will get built over and over again, after each of the other projects.
This could potentially be addressed by one of these solutions:
Allow the user to specify the order of "dependent builds"
Allow the user to specify some kind of "only trigger this if build was triggered by check-in or expicit build request"
Maintain a dependency tree (internally) of what build trigger which build and intelligently manage the build queue
Add support for changesets to eclipse plugin.
first class mercurial support would be nice (including remote run).
A REAL Clearcase UCM integration!
Xavier, could you tell in more details about it, please?
The ability to set only certain projects visible for guests. This might be due to licensing issues.
Kinsey,
TeamCity Enterprise allows you to set project visibility for guest. TeamCity Professional does not have per-project roles.
Enable support for changesets in eclipse plugin.
+1 for Eclipse changesets support
Post a Comment