Next TeamCity major release wishlist

Hi all!

We are starting with TeamCity 6.0 development and in case you have a list of favorite features, major improvements or killer features suggestions it's high time to let us know about them.
Not sure we will be able to handle all of them but your voices will make our choice more educated.

For minor issues or bugs, please ensure you voted for them in the issue tracker.
If you have suggestions on bigger items or entire new directions, please do not hesitate to add a comment in this thread or start a new one.

66 comments

Yegor,

TeamCity is really on the right track lets be clear about that.  My company is moving to the enterprise version very soon.  We obviously tried out a few of the other CI build servers such as Hudson, AntHill Pro, and ElectricCloud.  What really sold us on TeamCity was the private builds and the Visual Studio/IDE integration in addition to all the other major features and ease of use.  I would continue to improve that area as it is a major advantage with your software.

My top priority would be to see some of the major issues that have many votes or comments on addressed first from the issue tracker - as we are in the process of migrating our builds into TeamCity, having those issues addressed would have made a lot of areas much easier on us in the process, and I see many of those issues have been around for some time now.

Since evaluating some of the other software out there is still fresh in my mind, I will point out some of the major areas that we saw as advanatages over TeamCity:

  • Managing the lifecycle of the product.
    • Anthill Pro had a very robust way to monitor an application lifecycle from the build, into the testing phase, into the QA phase and so on.  In TeamCity, the built in support only cares about the build for the most part.  It would be nice to be able to track a build throught its whole life cycle and mark it in current states such as QA or RTM.
  • Workflows. It is very nice and simple to have a 7-step configuration, but many of our builds are much more complicated.  Again, Anthill pro and even Hudson allow you to configure the steps from start to finish in a single configuration. http://www.anthillpro.com/html/products/anthillpro/screenshots/workflow-config.html
  • GUI customization.  The simplicity works nicely for the main overview page for a limited number of project currently in TeamCity.  As we migrate more builds into TeamCity, the GUI isn't as flexible as some of the other systems.  It would be nice to maybe have the option to customize the GUI, as far as maybe have the option to turn on a tree view or even have maybe one more level above the TeamCity project level. An example is that I currently have ProductA version 2 in development with 10 configurations. It works nicely in that case, but now I am at a point where I am working on ProductA version1 ServicePack 1, ProductA version 2 special version, ProductA branch for a prototype, and I need to keep ProductA version 1 around because we may be working on more service packs or bug fixes. A tree structure or top level group would make that much easier to navigate.  Again, this might go back even to the lifecycle management.  The TeamCity GUI works great for the current development project, but normal projects just don't end and go away and everyone moves on to the newest version.  My example might look like rougly something like this:
        • Product A
          • Version1
            • Special Version
              • configurations here
            • RTM
              • configurations here
            • Service Pack 1
          • Version2
            • Development Branch
              • configurations here
            • Prototype
              • configurations here
            • Testing Suite
              • configurations here

  • Hudson has support for managing a build configuration that needs to be built and tested on a wide variety of platforms.  I am talking about the "matrix project" concept, that allows a build configurations to be parameterized and run over many different platforms, compilers, and so on. http://wiki.hudson-ci.org/display/HUDSON/Aboutncysa
  • The last area, may be the lack of plug-ins available.  I think it is realy great that TeamCity as good 1st tier support for the major build tools and it is really great when an open-source Plug-in is released by Jetbrains, but the number of plug-ins available for Hudson and the customization that those bring are incredible.  Just look at the list, http://wiki.hudson-ci.org/display/HUDSON/Plugins.  Maybe Jetbrains can support developers by creating an area for source control, project management, downloads, and history while moderating the projects and providing developer support would be great.  I don't want to see twenty different plug-ins that do the same thing, but for lower priortiy items that your company just doesn't have the demand or resources to provide it would be very helpful.  Our company would have no problem releasing a plugin as long as we could utilize others plugins.  We don't have the bandwidth to support multiple custom plugins internally, but we have the time to support at least one in return for other plugins.  
    • An example I can think of was that I recently saw a request to be able to monitor a directory for changes and trigger builds.  This is a pretty low priortiy item, but it might add huge value to some companies using your product.  There is a plugin available for Hudson that adds the Filesystem as a SCM - http://wiki.hudson-ci.org/display/HUDSON/File+System+SCM
    • I think you guys see the value of the plugins and the open source support as already demonstrated by you offering several open source plug-ins.

  • One that I haven't seen anyone pull off is the ability to have a master server with slave servers.

    • The obvious use would to have a failover if the master server goes down

    • It would also be great from a performance standpoint for geographically distributed teams to be able to have a slave server at the local site.  Maybe the main site handles the administration of the VCS roots, user admin, and agent management and those settings are mirrored to the slave servers.  The agents could be centrally managed and grouped by geographic region for instance for performance reasons.  Build triggers and artifacts could be shared across the servers.  For instance, site 1 may only care about Project A, B, and C, while site two may only care about Project D and E, but have a dependency on C.  This setup could give large distributed enterprise companies the benefit of a central build management, but still supply good performance across the company for builds, testing, and pre-tested commits/remote runs.

    • You would still have the ability to share common pieces of build logic by having the ability to share templates and copy and move build configurations.
    • Replication is even mentioned in the how to section of the documentation: http://confluence.jetbrains.net/display/TCD5/How+To...



Again, I am just pointing out some of the things that impressed us with the other CI systems out there.  We enjoy using your software and it is really changing the way we develop and build software. I can't wait to see what you have in store for version 6!

thanks,
NSN

0

When selecting a configuration template as the configuration for your build, how about the ability to no include certain sections without detaching from the template.
e.g i just want to use my svn section or a different runner but i still want to be linked to the other "global" sections

0

nospamnerd has made some very good points and I agree with all of them. Workflow and GUI customisation are on the top of my list today... though I expect the Project Matrix to soon be an important feature.

The only other minor wish is that TeamCity provides better notifications for Administrators and SuperUsers. Currently, most of the notifications are centered around Developers (which is a very good place to start) but having additional notifications would improve the product. Hudson already offers better features in this regard.

0

no spamnerd,

What really sold us on TeamCity was the private builds and the Visual Studio/IDE integration in addition to all the other major features and ease of use.

Whether there are any additional features that you would like to have in Visual Studio / IDE integration?

0

no spamnerd,

Thank you for your thoughts and suggestions!

Some brief comments to your points:

> Managing the lifecycle of the product.
TeamCity has some support for that (pin, tags, "Promote" action for a build), but this indeed can be extended. Can you list the most important requirements/needs in this relation?

> Workflows
This seems to be requested by the issue. Not sure we will pursue into allowing parallel steps, but multi-steps builds are in our top priorities for the next major.

> GUI customization
The example you described looks like project grouping. However you probably have more in mind then just grouping projects.
We too feel that the current Overview page is hard to use when the number of projects is large. This actually deserves a separate discussion.

> Matrix builds
Related issue for voting for those who did not yet. Do not forget to add a comment describing your case in detail!

> Lack of plug-ins available
Yes, the list is not large but it is growing.
We are ready to help anybody willing to write a plugin for TeamCity. Everybody interested in writing or sharing a plugin, do not hesitate to contact us (you can also use plugins forum).
As to "hosting", we do can provide source control, TeamCity builds, wiki and issue tracker for TeamCity plugin writers. e.g. we sort of do this already for AccuRev plugin.

> master server with slave servers
With at least some form of replication available, the major point seems to be performance. We will certainly look into this, but whether the best solution is multi-servers or some other is still to be evaluated.

Thank you for the input. Hope we will address some of the issues soon.

0

Tariq,

You already can use another VCS root (since 5.1) and can customize VCS checkout rules, but yes, the settings that you can override are limited. We plan to gradually extend the available options and at some point may arrive to the general approach that is requested by the Build Configurations inheritance issue.

0

Hi Yegor,

I have been using TeamCity for some years now, and I am overall very satisfied by the product and by your support as well. Here's a list of things that off the top of my mind I find myself wishing for:

    • Better handling of source control operations. Our codebase is quite large, and the repository not extremely well structured. These two things together imply that downloading large chuncks of the codebase (using checkout rules to exclude unneeded stuff) is a bottleneck and ends up representing more than half the time of the build configuration run duration. I'm not sure what specifically could be done to improve this situation, but for example it could be possible to configure TeamCity so that clean checkouts are done less frequently. Also the algorithm to calculate the name of the checkout directory implies that any change to checkout rules leads to a clean checkout, which might not be needed.
      Overall I think that although TC is already pretty smart when it comes to SCM management, it could be improved
    • Support for manual intervention during build process. Our build process requires manual intervention at times, for example to apply versioning to products. It would be cool, although probably not a common feature for a build system, especially a Web-based one, to have such a feature, but tp us it would be very useful.
    • Additional documentation about little known features. Although the documentation is already very good, sometimes I incur into something which is not well documented, or not documented at all. For example usage scenarios of build promotion/tags would be useful.
0

I would love to see the following integrations:

1. Sonar
2. More defect tracking tools (HP Quality Center is what we use)

0



Simone/Yegor,

I second "Support for manual intervention during build process".  We have coded logic into our current build scripts to allow us to pause the build while we fix an issue, wait for a fix from a developer, or even wait for a piece of network hardware to be repaired.  I guess a pause button that would have the ability to pause a running build is the request and maybe have some way to override the console output or build status.  For insance maybe a component broke and you are able to pause the build, fix the issue, and resume the build process while being able to set the build state as success.  We do this kind of stuff more often then we probably should be, but our software and process is large and complex.

I also like some of your thoughts on the source control operations.  In our current build scripts, one of the optimizations that we made is to run a clean check-out at the end of a build and a quick update at the start of the next build.  This way you ensure a clean build and don't have to incur the penalty in the time it takes to check-out.  Not sure if something like that could be done.  Even allowing for source operations to run in parallel if you had multiple check-out rules or VCS roots defined could give you a speed up in theory.

0

I second "Support for manual intervention during build process".  We have coded logic into our current build scripts to allow us to pause the build while we fix an issue, wait for a fix from a developer, or even wait for a piece of network hardware to be repaired.  I guess a pause button that would have the ability to pause a running build is the request and maybe have some way to override the console output or build status.  For insance maybe a component broke and you are able to pause the build, fix the issue, and resume the build process while being able to set the build state as success.  We do this kind of stuff more often then we probably should be, but our software and process is large and complex.


My needs are somewhat different, probably even more exotic For example, our current release process requires user intervention to close issues and changing version numbers. If parts of the Web UI could be scripted easily and could, for example, block the execution of a build configuration either at the beginning or during the build itself by prompting the use about some data to supply that would be very useful.

I also like some of your thoughts on the source control operations.  In our current build scripts, one of the optimizations that we made is to run a clean check-out at the end of a build and a quick update at the start of the next build.  This way you ensure a clean build and don't have to incur the penalty in the time it takes to check-out.  Not sure if something like that could be done.  Even allowing for source operations to run in parallel if you had multiple check-out rules or VCS roots defined could give you a speed up in theory.


I think there's a plugin called Swabra or something similar which you might find useful. I don't like the idea of performing a clean checkout at the end of each build because that would mean to make builds last much longer. However I didn't experiment yet with different combinations of agent/server side checkout, probably a good compromise is possible already. Off the top of my mind, for example, if checkout performance is a problem and since checkout directories names are hashed out from VCS roots and checkout rules, then making more builds share the same less restrictive checkout rules would mean that less clean gets would be done from the VCS.
0

Oh, yes TFS integration as an issue tracker would be cool too.

0

I commented some more on the GUI customization thread and wanted to point it out here because of some overlaps with my points on lifecycles/workflows.
http://jetbrains.net/devnet/message/5263684#5263684

I will get back to you on the other points, but most of your comments make sense to me.

-ns

0

1. Prioritise build configuration run order by using relative weights, with additional options to escalate a build based on time in a queue etc.
2. TFS issue tracker support
3. Integrated Dependency Management with Visual Studio. Currently I define a 'Lib' folder and place all my dependent dlls in there and I need to ensure these are the properly in sync, would be nice if I can get this folder to be synchronised by TC based on simple rules.

0

Alex,

Thank you for the input.

> 1. Prioritise build configuration run order by using relative weights, with additional options to escalate a build based on time in a queue etc.
The issue to vote for/watch for those who are also interested int he feature.
Actually, we already have a working prototype of a plugin that implements the feature and it will hopefuuly be relesead in the scope of 6.0 version EAP soon (weeks?).What we are not sure yet is whether manually assigning weights (and updating them!) is a viable approach. If you have more comments on this, please leave them in the issue.

> 2. TFS issue tracker support
Issue to vote for for those who are interested.

> 3. Integrated Dependency Management with Visual Studio. Currently I define a 'Lib' folder and place all my dependent dlls in there and I need to ensure these are the properly in sync, would be nice if I can get this folder to be synchronised by TC based on simple rules.

Can you please elaborate on this more? What kind of dependencies these dlls come from? Where do they reside? I would appreciate if you can create a new thread or leave comment in a related issue.

0

T D,

Here is an issue to gather Sonar votes. Please also leave comments on most immediate features that you need in the integration.

As to HP Quality Center integration, I am not sure this will get into our nearest plans, but you (or someone else) can write a Java plugin for it. Be sure to get to us for help in plugin writing if you need it.

0

Simone,

A brief comment to manual build intervention:
So far you may try to use "custom build run" dialog to enter values at the build start. If you need this to be supplied in the middle of the build, a workaround might be to break the build in two and ask for the property on the next build run. Other then that it seem you should be looking into a plugin or some build script customization that will address the need.

As to optimizing source control operations and documentation improvement: it would be helpful if you can describe your ideas and details of these in a separate thread when you encounter them. This way we can share thoughts on the issues and maybe come outwith some solution.

0

Dynamic VCS roots have been a long time coming so I hope to see it very soon: http://youtrack.jetbrains.net/issue/TW-5428  This is a major blocker for developer ease-of-use.

Enhanced project grouping and visibility options:  http://youtrack.jetbrains.net/issue/TW-705  Should fix major scaling issues related to maintaining servers with hundreds of configurations.

Artifact-based triggering:  http://youtrack.jetbrains.net/issue/TW-11553  Would allow the creation of an easier-to-track daisy-chain configuration.  Eg: Build -> Test -> Package -> Ship steps could all be homogenized.

0

Dave,

Thanks!

As the root needs for TW-5428 (Support variables in VCS roots, dynamic VCS root) can deviate, I'd appreciate if you can describe you case in detail in the comments to the issue.

0

> Managing the lifecycle of the product.
In addition to the GUI side of this which I commented on in your GUI thread, I guess with the pin, tags, and promote items, it would be nice to be able to automate those based on the outcome of the configuration and than be able to track that process.
So, if a compilation configartion is successful, I could apply a tag to the build, that would trigger the next configuration to possibly run some automated regressions.  Upon success of that step the build could be tagged with QA. Now maybe some manuall testing takes place.
After that, the test results maybe attached to that build and tagged with QA_DEPLOY for instance, which could trigger the build to be published.  Somehow the build history should be able to show those steps and outcomes and that whole process from the compilation to the deployment step is a build lifecycle.  It is one build with many steps that should be able to be viewed as a single process.

> Workflows
Multi-step builds would be a huge improvement!

> master server with slave servers
Yes, better performance would be a great thing and that was a big part of my intention, but lets not forget that having a single TeamCity server with no failover could lead to some major problems.  A companies whole build infrastructure could be halted by some bad hardware on the TeamCity server.

A few other items I wanted to point out:

Groups for build agents would be a big help.  It seems parabuild just added a similar feature with the build farms concept: http://www.viewtier.com/products/parabuild/new_in_parabuild_4_0/managing_build_farm_infrastructure.htm
Vote for the issue here
http://youtrack.jetbrains.net/issue/TW-11244

The last item I thought of would be to have some sort of state on a build configuration or project.  The state could be something like "production", "test", "private".  The state could control the notifications, history, and visibility of the project or configuration.
Maybe a configuration marked in "test" state would only show up for build admins and send notifications to them while development is done on that configuration before it is ready for public consumption.  A "private" state may only be visible to the build admin that marked the build as private - this would be more of a finer control than the "test" state.  The "production" state would make the configuration visible to all and turn on notifications.

0

I would like to see deployment to the Force.com cloud just like the one for Amazon.


0

Hi Yegor,

yes I think a plugin would be the best way to accomplish that. What I'd like to see is improved support for writing such plugins which influence the lifecycle of the build via human intervention. I honestly haven't looked much into writing custom plug-ins, but I think the current infrastructure is mostly general purpose, and writing such a plugin on top of that requires considerable effort and knowledge. If there was a layer on top of the current implementation which provides a workbench for writing such a plugin it would be very useful.

Cheers

0

If anyone has a way to interface with Quality Center over the network from Java I'd love to hear about it.  I'm still infuriated that there's no way to access a defect report in it via simple URL.

0

Support for cmake would be great!

0

Oh, one interesting feature would be to have a visual representation of dependencies between build configurations in terms of snapshot and artifact dependencies. A graph would be cool.

0

If you could way to specifically support web/servlet tests (i.e., JWebUnit) the way that JUnit is currently embedded and supported, complete with being able to capture coverage info, that would be fantastic.

I also like the dependency graph idea!

0

I have seen this request posted previously but I would like to remind you guys.
Audible Notification.
Simple but an affective hand slap especially with in an office environment.
Btw, thx for a great product.

0

Thomas,

Not sure TeamCity agent can be run in the Force.com cloud, but I may be lacking some knowledge about the service. Anyway, feel free to start a new thread on the feature to clear the details.

0

Helge,


Feel free to post a feature request about that detailing what feaures you need most. Not sure CMake will get into our priorities, but this can be implemeted as a plugin and the issue can serve as a good meeting point for everybody interested.

0

Simone,

Totally agree
Recently I was investigating a TeamCity setup and actually had to write a quick and dirty plugin that displayed the dependencies of a build configuraiton in easily browsable way.
Anyway, here is a place to vote and watch for the feature.

0

Please sign in to leave a comment.