News Uncategorized

Love TeamCity? Make it better!

Have you ever asked yourself why TeamCity is so cool? We found the answer a long time ago. TeamCity is great because of you, our users. You constantly suggest improvements, report bugs and discuss new functionality. Every time your energy and involvement motivate us to do our job better than we did before.

Documentation is an essential part of any product and TeamCity is not an exception. We constantly improve the documentation and make it more valuable to you. On the other hand, we know there’s a wide field for improvements and some important topics are missed.

With new TeamCity 8.0 on its way we think time for change has come. We start reworking the documentation and we invite you to help us with it again. We’d love to hear what you do not like or miss in current documentation or you missed when you opened it for a first time.

Leave your mark in history by commenting here or in opened issue.

Help us to become better and… happy building!

Comments below can no longer be edited.

7 Responses to Love TeamCity? Make it better!

  1. Avatar

    andy says:

    April 8, 2013

    The documentation for installing TC Agents is really bad.

    I had a lot of struggle to get it to work, the documentation is also confusing with all the various ways to install it, please separate the various ways better.

    The most difficult part to get right was the security requirements for the local user that the agent should run under (including the SubInACL tool).

    A clear step by step guide for Win7/8/Server 2003/2008/2012 should be created.

    MAke it clearer if I need to install GIT (mysysgit?) on the agents? anything else that is recomended to be installed on the agents?

    The best practices around command line runners should be improved, also the flow of what files and directories that are dynamically created during a build should be better explained.

    Perhaps a copy of the last XX

    Any other best practices on how to setup the agent and as well how to verify that the setup is complete and final?

    I installed the TC server and agent from the save setup file, but why does the server want to update the agent directly? (I got some update hanged) error as well.

    Better documentation and best practices around the command line runner, if I run a build script solution like Finalbuilder, how do I integrate that with TC?

  2. Avatar

    Morphean says:

    April 11, 2013

    Make team city integrate with gitolite repos more easily. At the moment there is no way to add a specific ssh user / key.

    I have switched back to Hudson/Jenkins specifically for this reason..

  3. Avatar

    Matt says:

    April 11, 2013

    I had some trouble trying to get TeamCity running with SQL Server using integrated (Windows) authentication. The documentation doesn’t explain that you need to use an older version of the JDBC drivers to get it working.

  4. Avatar

    MattOhare says:

    April 12, 2013

    It would be nice to configure the TC web application to show time elapsed instead of time remaining. Many of our projects vary so much in deploying time from one deployment to another that ‘remaining’ is completely useless and we have to keep hovering over the ‘remainig’ to get elapsed.

  5. Avatar

    Boaz says:

    April 14, 2013

    ‘Changes’ that are visible for a configuration should include the changes that were part of the snapshot dependency.
    We are using one build as a sub-product of a bigger build. I can’t see the entire picture of what’s new in the main build, because changes of the dependent builds aren’t displayed.

  6. Avatar

    Michael says:

    April 16, 2013

    Documentation about clean up rules can be improved.
    For example: “Clean artifacts – and keep history and statistical data”
    which artefacts will be cleaned, only the checkout directory or the artifacts generated by a build (which I assume are stored in the database)?
    What is the definition of statistical data?

  7. Avatar

    Dave W says:

    May 1, 2013

    I’d like a better explanation of this:

    “A “suitable” build in terms of snapshot dependencies is the one which uses the same sources snapshot. ….. If VCS settings are different (VCS roots or checkout rules), then “same sources snapshot” revisions means revisions corresponding one to each other in terms of being current at some moment in time.”

    Specifically, what does “curernt at some moment in time” actually mean? I can’t quite figure this behavior out.

Discover more