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
Comment actions Permalink

Mark,

Looks like a separate topic to discuss and pinpoint the necessary configuration and features of TeamCity that may be lacking in this regard.

0
Comment actions Permalink

Steven,

Thanks for a reminder.
Here is a related plugin that supports that with a hardware bunny.

So far looks like a great plugin idea and it is really easy to write one (e.g. use the aforementioned plugin as an example).

0
Comment actions Permalink

We would love to see some functionality similar to AutoMate (http://www.networkautomation.com/automate/7/) that

1) allows to trigger builds when a file is added/changed on a file system (local/network)

2) has the ability to build configuration "scripts" via TC web GUI (useful for TC users without "real" programming skills).

0
Comment actions Permalink

Oleg,

> 1) allows to trigger builds when a file is added/changed on a file system (local/network)

The issue to vote for. Not a big deal, has chances to be implemented by one of us as a plugin if no external implementation is published soon.

> 2) has the ability to build configuration "scripts" via TC web GUI (useful for TC users without "real" programming skills).

Not sure that developing a visual build "language" falls under TeamCity's main goals, but there seems to be no obstacles why this can't be implemented as an external plugin.

0
Comment actions Permalink

I'd like the ability to restrict access to specific build artifacts based on a user role.

For example, I'd like to tag builds as "QA" when I released them to our QA department. A QA Role would only allow access to builds marked with a specific tag (e.g. QA and Release).

0
Comment actions Permalink

I am really happy with what TeamCity is right now.

I'm always scared that TeamCity might "bloat" into something slow and hard to maintain with all the features you're adding and the pace at which you're adding them, but somehow you manage to keep it simple, fast and neat.

If there's one thing I could wish for, it would be the limits of the professional edition to be rebalanced to 10 users and 40 projects (instead of 20 users and 20 projects now). I consider a business with 10 active developers to be quite capable of paying for an enterprise license, but 20 projects are easily exceeded even by a poor shmuck such as myself ;-)

Alternatively, an affordable license for indie developers would do. I love TeamCity and would gladly pay for your great work, but 2000,- EUR are way beyond what I can afford in the foreseeable future. The original 200,- EUR as it was with TeamCity 2.0 had me close to buying it (even though I was doing this purely as a hobby back then).

0
Comment actions Permalink

We have a series of Integration tests that take a long time to run, so they are broken into a chain of build configurations.  Each of those generates coverage data, so at the end I have written a small Ant script that consolidates the coverage artifacts from the builds and creates a single coverage report.  However, in doing that I found that Teamcity does not make the full EMMA distribution available, so I had to find the version of EMMA you are packaging and include the jars that export the EMMA Ant tasks.  Obviously, it would be helpful if you could make all of EMMA available to builds.

0
Comment actions Permalink

One nice feature would be the ability to propagate SCM changes to dependent builds. We have release builds that push the latest version of a project out to the production/QA environments, so it would be nice to know what is going to be pushed out there. We also have triggers that rebuild a project when a core, shared library has been successfully released to our dependency manager. Some way to propagate the change list between dependent projects so they can be easily seen and understood would be very helpful.

0
Comment actions Permalink

Here is my wish list :

  1. Enable to input tags for projects (for search, filtering purpose)
  2. In the dashboard/TC tray, enable to group projects.The actual visibility feature is good but it does not cover all the needs.  Conditional display would be great too. (ex for each project you have a property tags or Group which will be  used in the dashboard to group project; very usefull when you have a  loooooooots of project)
  3. Define templates of templates (usefull if you want a single entry point for all your configuration with each one depending on another; if any update is needed, it occurs at one point => usefull when you have lots of project which depends on => use of chaining pattern)
  4. Override some properties of template in the build configuration. Sometime you just need to override some properties of a template, however you have to create a new a full configuration. With this features, exceptions (slitly difference in configurations) will be only on the overriden properties => enable better consitency, flexibility & effortless configuration mechanism
  5. Define authorization on build configuration (not only on the project. Ex : I want to allow all the developpers to run the build configuration but not the delivery conf (only the integrator or some one in a precise group should in this case)
  6. Define pre-process & post process within the same runner configuration for all runner would be a good thing, but at least for the sln runner would be wonderful (post & pre runner).Ex: I have a custom process to retrieve dependencies & I don't want to split the tasks & use artifacts to exchange the files. I would like to define my sln runner define, a pre-process with a specific runner which would work in the same working directory and a custom post process.
  7. Enable dynamics variables (user input from tray) like ccnet 1.5. The dynamics variables would be inputed by the user who run the build : He will provide the dynamics value otherwise the process will use the mandatory default value. This could be a good way to handle build of temporary branche & it is a nice way to handle patch/fix where only the path in the CVS differ with everything else is identical (why create a new configuration for those ?)
  8. Better tool for LDAP configuration & Format features with ability to concat value in addition to LDAP Request result. Ex: I want to build my jabber with this format : LdapRequestValueFirstName + "." + LdapRequestValueLastName + "@jaber-"+ Domain
  9. Provide a way for SSO (Single Sign On) for Active Directory / LDAP
  10. More Built in Issue tracker plugin (Gemini, yeah!!!)
  11. Launch build from Teamcity Tray (should be more than a notifier)
  12. Enable to configure custom display in the Teamcity Tray (of filter by tags)


I think that with at last the 8 first features, Teamcity would be really terrific and better than ever

0
Comment actions Permalink

I really agree with most of the points listed by Sanosuke. I will try to add to the discussion:

Define templates of templates (usefull if you want a single entry point for all your configuration as each one depends on the other if any update is need it occurs at one point => usefull when you have lots of project which depends on => use of chaining pattern)


Not having at least a base template causes us a lot of additional work.  For instance we have a build that covers Windows and Linux and targets NAnt for the Runner.  We have two templates defined for the for builds and they only differe by the Target framework.  So when we have to make adjustments to the build, we have to go and make sure we covered both templates.

Override some properties of template in the build configuration. Sometime you just need to override some properties of a template, however you have to create a new a full configuration. However with this features, exceptions (slitly difference configraution) will be only on the overrided properties => enable better consitency, flexibility & effortless configuration mechanishm

I think for us, the limiting issues are with any options that use a check-box.  If we could make that value a parameter, that would eliminate a huge amount of duplication.  Take for instance you have a template that has the swabra plugin turned on.  Maybe for my daily build I want the "Ensure clean checkout directory" turned on and for my hourly builds, that option isn't important.  I currently have to have two templates to achive this, which takes away some of the power that the templates give you.
Another use, could be to run a custom build.  Maybe I just need to patch something and I don't want clean to run.  It would be nice to just set a property to override the checkbox values.

Define authorization on build configuration (not only on the project. Ex : I want to allow all the developpers to run hte build configuration but not the delivery conf (only the integrator or some one in a precise group should in this case)

This limitation has caused us to have to create two seperate projects for one build, with one project being the official stuff that developers shouldn't run, and the other with the configurations that developers are allowed to run.
It would also be nice if on the user Administration->Assign roles, there was an option to globally exclude certain projects instead of granting the role on selected projects.

Point 6 looks useful and I believe this on has been hit on already "define multiple build runners"

thanks.

0
Comment actions Permalink

I would like to add this too :

  • 13 : Extends the template features by adding more predefined variable and enable to access more properties. For example I would like to use the build description as a parameter in one of my process/runner configuration : %system.teamcity.buildConfigurationDescription%. In fact, it would be great to be able to access any configurable parameters in a generic way. This is important because it is a requirement to define flexible and "powerful" templates; Indeed the parameters need to be generic and not titly couple to a project/configuration. Teamcity should infer the variables' value according to the current context (not the user concern).
  • 14 : Add custom fields for Project / Build configuration : The idea is the following : I want to define a specific template for my build configuration and all my runner configuration (args, etc) whould be based on the general settings. I would like to have a custom fields named (...wait for it...) "custom field" that any user would filled. What I really want to do in reallity is enable my users to access & modify general settings of configuration which are usally simple to understand without to worry about the runner configuration or anything else. Thus a new project is registred in the system, I just need to create a configuration from my template and ask the user to fill the custom template with some value and ther we go... a new project with only one input user conf...
    • %system.teamcity.buildConfigurationCustomField%
    • %system.teamcity.projectCustomField%

You may not like the last feature as it can be used to input anything... but in the same time, it can really be a life saver feat for users...

Stay tuned,
I have more to say :), more things I would like. More in my next post

    0
    Comment actions Permalink

    Well, that was a nice post. I see, that we have suffer more or less the same limitation & share the same frustration.
    Thanks for adding in.

    I really hope that what we report will be consider .
    Let's make Teamcity a must have!!!  I believe in this soft & in this company.
    Good work again Jet Brains!!!
    Tools by developpers for developpers, I guess this is definitely not a lie (throught I already knew it since Intelly J)

    0
    Comment actions Permalink

    As promissed :

    - 15 : Project Template using Configuration template : Several projects may execute the same build configurations... and it is usually the case. In fact, in some situation, event the VCS settings are the same, only the checkout rule differ...
    This would be awesome to have this feature... xtreme conf reduction

    - 16 : Autogenerated Project based on Project template : Usually in a  you follow a pattern to organize project in your VCS. And I would like TC to create automatically the project based on a general VCS settings defined. this could lead to auto add or remove/archive project according to your source repository without additional action.

    - 17 : Autogenerate Project Script : The ability to define a script (custom script to handle/customize the action to perform in the autogenerated process. This could be used to tell TC how to discover and how/what to perform. This feature can be related (or not) to the previous one.

    I will more again...
    In my next post

    0
    Comment actions Permalink

    We really need triggers with parameters.  This feature would make TC 100 x more flexible.  We constantly are trying to hack around this limitation now: TW-6439

    0
    Comment actions Permalink

    We are starting to use TeamCity more and more for automated deployments to Dev, QA, UAT and Production, so we need control over who can see/press the Run button within a project. Can we get this: http://youtrack.jetbrains.net/issue/TW-5884? It's #5 on Sano's list, but with 4 possible groups of people who can trigger these deployments.

    0
    Comment actions Permalink

    Adam,

    Multiple build runners are already under development. Hopefully EAP build with the feature will appear in one-two months.

    0
    Comment actions Permalink

    Markus,

    Thank you for valuing our work.

    Shifting professional edition limitations is more a marketing quesiton and I cannot comment here so far.

    Just want to point out that with a certain level of risc you can probably use TeamCity free of charge by using EAP builds and gettings evaluation license for the periods when EAP has been not yet started for the new version. This way you use TeamCity for free and help us test the product better :)

    0
    Comment actions Permalink

    Mark,

    Unfortunately, EMMA does not look like a live product, so our focus with coverage is likely to move from EMMA to JetBrains-developed IntelliJ IDEA covearage tool. It is not available (yet?) as a separate tool, but is bundled with IntelliJ IDEA and TeamCity. Feel free to file details on what you need into our tracker.

    0
    Comment actions Permalink

    Issue to vote for/watch/add your details to their comments: TW-2576 Include changes from changed artifact dependencies in the build's changes
    See also related issues.

    0
    Comment actions Permalink

    Sano,

    Thank you for the items and details, this was exactly the post I created the thread for.

    Just some pointers to our issue tracker so that all interested can vote (thus making the interest measurable), watch and add own use cases to them.

    >    1. Enable to input tags for projects (for search, filtering purpose)
    and
    >    2. In the dashboard/TC tray, enable to group projects.
    TW-705 Allow projects to be grouped into categories and viewed/managed by these groupings

    >    3. Define templates of templates
    TW-12153 Build template nested/meta-template

    >    4. Override some properties of template in the build
    TW-3350 Build Configurations inheritance

    >    5. Define authorization on build configuration
    TW-5884 Add Permissions to Build Configurations

    >    6. Define pre-process & post process within the same runner
    TW-3660 Support multiple build runners per build configuration

    >    7. Enable dynamics variables (user input from tray)
    You already can override any property of a build in custom run build dialog. But the property references are not yet supported in the VCS roots settings.
    Here is the issue for that:
    TW-5428 Support variables in VCS roots, dynamic VCS roots

    >    8. Better tool for LDAP configuration & Format features with ability to concat value in addition to LDAP Request result
    TW-12599 Ability to edit LDAP integration settings from web UI
    TW-12600 Ability to use several LDAP properties to get TeamCity user property on user synchronization


    >    9. Provide a way for SSO (Single Sign On) for Active Directory / LDAP
    An issue on that with details on whether you use SSO already and others would be great.
    A related one is TW-6885 (NTML authentication SSO support), but this will not coexist with TeamCity LDAP integration.


    >   10. More Built in Issue tracker plugin (Gemini, yeah!!!)
    TW-11574 Include Countersoft Gemini in the supported issue trackers
    As Gemini does not look very popular, how about writing a TeamCity plugin to support it?

    >   11. Launch build from Teamcity Tray (should be more than a notifier)
    TW-9341 Running builds from Windows Notifier
    Definitely needs more votes to be considered.

    >   12. Enable to configure custom display in the Teamcity Tray (of filter by tags)
    If this is not part of TW-705, it should be filed separately with some use cases description.


    For the 1 and 2 - we do understand the necessity of the feature and will try to add it at our earliest ability. Not sure about the nearest major release, but the next one have good chances.
    3 - quite possible to add, 4 - great feature, but not sure how fast we can implement it fully.
    I am not sure that 5 is something we will be able to do in the nearest release, but it's important for the further planning to know that these features are necessary for many.
    6 is already under way, expect to try it in EAP in one-two months and do not forget to let us know how it covers your needs.
    7 - would love to add it in 6.0, will see how it goes.
    8 and up really depend on the votes and more requests for the features. Some easier ones may be added, but so far they are not on the priority lists that we have.

    And thank you again for the list and details!

    0
    Comment actions Permalink

    Sano,

    > more predefined variable and enable to access more properties

    The current appropriate way to do this is to write your own plugin that will add the necessary properties. You can use the Groovy plug plugin and add just a several lines to add new properties, even while the server is running.

    > Add custom fields for Project / Build configuration
    Sounds like: TW-5327 Support user-level build configuration settings

    0
    Comment actions Permalink

    > Project Template
    TW-3287 Project templates
    However, I'd appreciate a comment into the issue detailing the use cases.

    > Autogenerated Project
    > Autogenerate Project Script
    Looks like a plugin :)

    0
    Comment actions Permalink

    Any plans for dotCover integration?

    0
    Comment actions Permalink

    Oleg,

    Yes, we plan to provide option to collect dorCover covarage at least the same way as NCover/PartCover. This still requires some effort on HTML report generation and other, so the exact scope of the feature is to be determined.

    0
    Comment actions Permalink

    Yegor,

    Sounds great! Any idea on dotCover licensing/pricing when it comes to TC integration? One license per build machine? Per agent? Paid? Free/included with agent license? I would be willing to discuss this offline to outline our needs and wishes. I think JB has an obvious competitor, and we are actually trying to decide whether to invest in their product or wait for dotCover.

    0
    Comment actions Permalink

    Oleg,

    It's a bit early for us to discuss pricing.

    One of the user-friendly options that we have in mind (please, please, this may change a great deal for the actual release) is that user is able to gather coverage in TeamCity without any license and will only need one for Visual Studio integration. I am afraid we will not be able to settle on any specific details on integration until near the release.

    It would be good if you can describe pricing that would make you chose dotCover over another product. Probably in another thread or mail.

    0
    Comment actions Permalink

    There I go :
    - 18 : Provide a top and bottom button to configure visible project (I have 45 projects and it's not easy to parameterize this). Maybe by enable setting custom index with a auto reordering... well the idea is to enable an easy configuration for the users in this particular case
    - 19 : Provide more interaction with agent statistics and matix:

    • Statistics : For example I have a nightly build on all the project (45). What I want to have is a way to "zoom" on the precise interval : 05/07/2010 20:00 - 05/07/2010 21:00 and have all my stats updated (CPU usage in this interval, build duration, total build time (globale), total build time by agent, etc... ).
    • Matrix : Same thing here, I would like to do more things. Here I have a total time but maybe there are build conf I don't want to consider... so I need more filtering features there, more grouping feature to. I would like to define my own custom  filter and I would like to have access to more information.

        Indeed, for me, Statistics & Matrix must be able to answer (well at leat help me to) question about scalability. Do I have enought agent ? Do I have enougth CPU/RAM/System ressources allocated to My CI Server?
        By providing theses information built in teamcity, it will be easier to convice higher-up to buy new agents or increase the allocated ressources...
    - 20 : Dedicated agent (agent restriction/requirement ) : you can prevent build to run on an agent by adding requirement information. But I would like to do in it in the other way. I would like to define an agent and configure it to be available only for precise build. It is not the same, because the agent would not be usable for builds which does'nt define a precise requirement.
    The idea behind all this is to have a dedicated agent. For example want to have an agent dedicated for all build which include Unit Test (because it take time) I don't want to impact the usal build process. So I want to have a dedicated agent which will only run eligible build.  Indeed when you have lots of configuration, it's easy to define restriction @ one point.

    This is it for now...

    More in my next post

    0
    Comment actions Permalink

    For auto generated project, the idea is to provide an uri :
    cvs_app:/server@user:password/cvs_path/project_solution_file (or compatible)
    ex: svn:/svnserver@sano:sano/projects/teamcity/TC.sln

    An automaticaly, a build configuration is generated with default CVS settings (no checkout rules -server mode) and sln runner...
    But you may be right... it could be a plugin...

    0

    Please sign in to leave a comment.