 |
You are viewing documentation of TeamCity 6.5.x, which is not the most recent released version of TeamCity. Please refer to the listing to choose another version. |
Less restrictions in Professional EditionStarting with TeamCity 6.5 all Professional Edition restrictions were removed except one: the maximum number of build configurations (20).
This basically means that all features of the Enterprise Edition are now available in Professional Edition. Remote run on changes in DVCS branchesTeamCity provides a more natural way to start remote run builds with distributed version control systems. As opposed to usual version control systems, in DVCSs branches are used extensively. Usually developers implement some feature in their own branch and then push their changes to the master branch in main repository. It is tedious to create separate build configurations in TeamCity server for each such branch, that is why now there is a better solution. If you are using Git or Mercurial in your project you can add special build trigger called "Branch Remote Run" to a build configuration. This build trigger will watch for commits into the branches of this build configuration VCS roots. If a commit is detected and if branch name matches to specific pattern, trigger will add personal build to the build queue. Enhanced Build ParametersParameterized Version Control System rootsTeamCity now supports parameter references in text fields in VCS root settings (except password fields). This way you can have a VCS root shared among several projects and customize it significantly in certain build configurations. It is also possible to start custom build and change some VCS parameter which, for example, affects a branch name. But in this case it is recommended to run such build as personal build so that it won't affect build history for other users. Project-level parametersYou can specify project-level parameters which act as default parameters for each build configuration and template in the project. Parameters completionAnywhere you see the Note that parameters completion also works in "Run custom build" dialog. Parameters of a buildEach build now publishes the final set of parameters passed to it when it started on agent. You can see all of them on the "Build Parameters" tab of the finished build. Restyled web interfaceTeamCity 6.5 introduces new, restyled web interface - more lightweight, more modern looking and hopefully more convenient. Note, that we no longer load content of the projects collapsed on the Overview page. This significantly quickens up the Overview page. Tests groupingIn many places where lists of tests are shown, the tests can now be grouped by package. This applies to build results page, Current Problems page, My Changes and so on. This is intended to help identifying common problems faster. Test failures mutingTeamCity provides a way to mute some of the failing tests so they won't affect build status allowing to manage your projects more efficiently. This feature is useful when some tests fail for some known reason, but it is currently not possible to fix them. For example, responsible developer is on vacation, or you are waiting for the system administrators to fix the environment, or the test is failing intentionally, for instance, if required functionality is not yet written (TDD), or the test is flickering (fails from time to time for unknown reason). In these cases you can mute such failure to avoid unnecessary disturbance of other developers. Test muting is potentially dangerous operation, that is why it is not available to Project Developer role by default. Only users with Project Administrator role can mute tests in the project. Responsibility renamed to InvestigationBased on feedback from our users we decided to rename "Responsibility" to "Investigation". The main reason for such rename is to avoid unnecessary friction in teams when someone assigns other developer as responsible. To our opinion term "Investigation" sounds more polite. We also reworked "Bulk mode" for investigator assignment. Now, anywhere where test grouping present you'll see "Bulk mode" link which adds checkboxes for the tests. Reworked My Changes pageDetailed data for each change is now shown on tabs. You can change tabs for the currently selected change with Tab/Shift+Tab keyboard shortcut. We also added a tab with suspicious builds with your change. For personal changes, all builds are shown. Problems which have an investigator are not considered critical (unless you are investigating the problem).
Audit of project configuration changesAudit log is now able to track changes in the project and build configuration settings. In the project or build configuration administration pages you can now see the name of the user who modified project or build configuration, as well as a link to the changes themselves. Since project and build configuration settings are stored on disk in plain xml, the link will just open the usual TeamCity diff window showing changes in these xml files. Build stepsTeamCity 6.5 supports names for Build steps. The names are shown in the build log and in Project administration screens. Additionally, you can now copy build steps, and reorder them even if build configuration is inherited from a template. This means that in the inherited build configuration you can insert custom build steps at any place, before, between, or after the inherited steps, in any order. However, the order of inherited build steps can be changed in the template only. AgentsAgents JVM upgradeTeamCity code base is evolving. Right now TeamCity server and agents can work under Java 1.5, but at some point we can decide to switch to Java 1.6 or later. Such switch is good not only for us, TeamCity developers, but for our users too, because some of the Java 1.6 features can finally provide additional functionality for TeamCity users. Not to mention that usually more recent versions of Java are faster than previous versions. It is not a problem to upgrade Java used by the server, but it is not so easy to upgrade Java used by agents, simply because there can be a lot of them. In TeamCity 6.5 we added a feature which can simplify task of agent Java upgrade. TeamCity is able to detect version of Java used by the agent and offer a switch to Java 1.6 if such Java is found on the agent. Remote build agent installationTeamCity provides new, experimental way to install build agents on the machines in your network, or in the cloud. The agent distribution is pushed on a Unix machine (by SSH) or on a Windows machine (with help of Sysinternals psexec), is installed there, and is configured and started automatically. For this to work, TeamCity needs to know credentials of the user on a remote machine with permissions necessary to install software. Also since TeamCity is using SysInternals psexec, push of the agent on Windows machine is only possible if server is installed on Windows.
Agents parameters reportWith the help of this report administrator can find which agents have particular property and with which values. Amazon Elastic Cloud integration improvementsWe reworked user interface for the Elastic cloud profile setup. Now, when you setup new Cloud profile, TeamCity will fetch many Amazon EC2 parameters from the Amazon itself, so you'll see actual values for availability zones, security groups, and so on. Additionally, our integration with Amazon EC2 now supports Virtual Private Clouds. IDE integrationVS-addin integrates with JetBrains dotCover 1.1New version of TeamCity VS-addin can download dotCover test coverage snapshots from the TeamCity server and open them right in the dotCover installed in your Visual Studio locally. Thus there is no need to run coverage locally. Just take it from the server. This only works with JetBrains dotCover 1.1. Filtering of data by current projectBy default, data shown by IDE plugins (projects, changes, and so on) are filtered by currently opened project. So if you have a project opened, you'll see a reduced set of build configurations, i.e. you'll see only those configurations which are building the sources of the project opened in IDE. In previous versions of IDE plugins we had this functionality in "Remote Run" dialog only. Now it affects the whole UI of the IDE plugin. Note, that per-project filtering can be disabled via plugin settings. .NET specific featuresAssemblyInfo patcherIn .NET world to set a build number to an assembly, you need to patch AssemblyInfo.cs files. New build feature simplifies this procedure. Just specify version format and the rest will be done automatically.
PowerShell runnerYou could start PowerShell scripts with help of command line runner in earlier versions of TeamCity. But since PowerShell is a very popular tool for .NET developers we decided it worths to support it natively in TeamCity. MSpec test runnerAmong BDD frameworks for .NET MSpec is probably the most popular. The official builds of MSpec are built using TeamCity. And now we have built-in MSpec runner designed specifically to run MSpec tests.
.NET process runner.NET process runner is able to run any .NET assembly under selected .NET Framework version and platform, optionally with .NET code coverage. For example, you can use it to run xUnit, Gallio or other .NET test runner, for which TeamCity does not have dedicated runner. XML Report Processing build featureXML Report Processing functionality has been extracted to separate build feature. The advantage is that you can keep all XML Report settings in one place (in TeamCity 6.0 they were distributed among build steps). Additionally this build feature has got support for Google Test and JSLint reports.
Disk Space build featureThis build feature is able to check whether an agent has disk space required for the build, and if not, it will delete some files on agent (like inactive checkout directories of other projects, artifact dependencies caches and so on) to satisfy build disk space requirements. Other improvements
Previous Releases |
