While we are developing TeamCity 7.0, some important fixes are being back-ported to 6.5.x branch to deliver the fixes to you earlier then in 7.0 release.
Latest branch snapshot is released as 6.5.5 today and is available from the official download page.
Update is recommended for all users as there were some performance improvements. See the full list of fixed issues.
Data format is the same as in all 6.5.x releases, so if you are already on 6.5.x, it is possible to downgrade if necessary. Anyway, creating the backup before the upgrade is highly recommended.
Thursday, October 27, 2011
Tuesday, October 11, 2011
TeamCity 7.0 EAP build 20334: Dependencies Graph, ReSharper-Powered Inspections and More
And here we are with a new snapshot of the current TeamCity 7.0 state: EAP build 20334.
This build adds several highly voted features:
Dedicated setting for per-checkin builds in VCS trigger. If your builds are fast and you have enough agents you can now tick the option to ensure TeamCity includes no more then a single new change in a build. This could have been emulated with the quiet period setting for a long time, but now it works more reliably and is more obvious to use. BTW, we used the approach for R# builds before their release. That bit quite a bit of our agents farm but the approach gave the team more confidence in the changes and that proved very useful.
Visualization of build's snapshot dependencies graph. Build's Dependencies tab was reworked to display the entire graph of the build chain. The view allows to see the big picture if your setup is not too complex. We have thought on moving it further, but need your feedback to adjust our plans. If you use snapshot dependencies much, try installing this EAP build as a test server, share your graphs and let us know what would you like from it.
Ability to ask for certain properties on manual build run. This has been added as a part of introducing "meta-data" for build configuration properties: display label, type, required flag. So far this is configured via a tricky syntax, but is likely to be improved if the feature is well-received.
For you, Git and Mercurial users, we have added visualization of changes' parent/child relationships on Change Log tab of a build configuration.
And for you, .Net teams, we have bundled a ReSharper-powered tool that allows to run solution-wide analysis inside TeamCity and browse the results in the browser.
Read all the details in the release notes or look through the resolved issues.
While we use this EAP build on our production server, it is not recommended to use it on yours if you cannot rollback to the latest stable TeamCity (6.5.4) losing all the data collected in this EAP version. If you risk, ensure you have a good backup beforehand!
However, trying the features on a test installation and letting us know whether it covers your needs or not is highly anticipated.
This build adds several highly voted features:
Dedicated setting for per-checkin builds in VCS trigger. If your builds are fast and you have enough agents you can now tick the option to ensure TeamCity includes no more then a single new change in a build. This could have been emulated with the quiet period setting for a long time, but now it works more reliably and is more obvious to use. BTW, we used the approach for R# builds before their release. That bit quite a bit of our agents farm but the approach gave the team more confidence in the changes and that proved very useful.
Visualization of build's snapshot dependencies graph. Build's Dependencies tab was reworked to display the entire graph of the build chain. The view allows to see the big picture if your setup is not too complex. We have thought on moving it further, but need your feedback to adjust our plans. If you use snapshot dependencies much, try installing this EAP build as a test server, share your graphs and let us know what would you like from it.
Ability to ask for certain properties on manual build run. This has been added as a part of introducing "meta-data" for build configuration properties: display label, type, required flag. So far this is configured via a tricky syntax, but is likely to be improved if the feature is well-received.
For you, Git and Mercurial users, we have added visualization of changes' parent/child relationships on Change Log tab of a build configuration.
And for you, .Net teams, we have bundled a ReSharper-powered tool that allows to run solution-wide analysis inside TeamCity and browse the results in the browser.
Read all the details in the release notes or look through the resolved issues.
While we use this EAP build on our production server, it is not recommended to use it on yours if you cannot rollback to the latest stable TeamCity (6.5.4) losing all the data collected in this EAP version. If you risk, ensure you have a good backup beforehand!
However, trying the features on a test installation and letting us know whether it covers your needs or not is highly anticipated.
Tuesday, September 20, 2011
TeamCity 6.5.4: BugFix Update
We've just published a bugfix update for 6.5.x branch. Nothing really new, just fixes.
Update is recommended for all users as the build includes various performance improvements throughout the system.
While creating a backup is always recommended, the version uses the same data format, so if something goes wrong with it, you can downgrade to any of 6.5.x builds.
Update is recommended for all users as the build includes various performance improvements throughout the system.
While creating a backup is always recommended, the version uses the same data format, so if something goes wrong with it, you can downgrade to any of 6.5.x builds.
Thursday, September 1, 2011
TeamCity 7.0 EAP is Open: Agent Pools, Fail Build on Metric Change and More
So the codename for the next TeamCity major version (7.0) is to start with F. Not that much of a choice from Indian F-cities, so a tiny one, but most pleasantly sounding to the ears of our team: Faradi.
We are still to define 7.0 release date, but so far it seems like we will target it for the first quarter of 2012.
The good news are that you can try some of the features of upcoming 7.0 now: check the EAP release.
This build introduces features that will be further improved (based on your feedback!) to develop into solid features of 7.0.
As one of the focuses of 7.0 we plan various means to speed up your builds. This EAP starts the trend and introduces:
Check the full list and details on the new additions in the EAP change log.
This EAP updates the data structure, so you will not be able to downgrade to 6.5.x releases after the upgrade. Consider checking EAP features on a test server or prepare to restore 6.5.x server from backup if something goes wrong.
Hope you will take time to look into the features and let us know what you think.
We are still to define 7.0 release date, but so far it seems like we will target it for the first quarter of 2012.
The good news are that you can try some of the features of upcoming 7.0 now: check the EAP release.
This build introduces features that will be further improved (based on your feedback!) to develop into solid features of 7.0.
As one of the focuses of 7.0 we plan various means to speed up your builds. This EAP starts the trend and introduces:
- Agent Pools - allows to divide the agents into groups assigned to sets of projects, so you can dedicate more resources to specific projects easily;
- Incremental Tests Running - support for selective tests running based on project model dependencies and the build's changes. This is available for IntelliJ IDEA project runner, Gradle and Maven runners. The functionality is new, so expect issues and make sure we know them;
- Build Performance Monitor - build-level report to analyze CPU, memory and disk usage on the agent machines.
Check the full list and details on the new additions in the EAP change log.
This EAP updates the data structure, so you will not be able to downgrade to 6.5.x releases after the upgrade. Consider checking EAP features on a test server or prepare to restore 6.5.x server from backup if something goes wrong.
Hope you will take time to look into the features and let us know what you think.
Saturday, August 6, 2011
TeamCity 6.5.3: BugFix Update
Here is a new update with the latest fixes for 6.5.x installations.
Data format is still the same, so you can downgrade to earlier 6.5.x versions if you need this for some reason.
We are mostly working on next major TeamCity version now, only integrating critical or easy fixes into 6.5.x branch. We will publish first 7.0 EAP in about three weeks.
BTW, if you are attending Agile 2011 in Salt Lake City next week, you are welcome to drop by JetBrains booth there for a live chat on TeamCity, YouTrack or other JetBrains products.
Data format is still the same, so you can downgrade to earlier 6.5.x versions if you need this for some reason.
We are mostly working on next major TeamCity version now, only integrating critical or easy fixes into 6.5.x branch. We will publish first 7.0 EAP in about three weeks.
BTW, if you are attending Agile 2011 in Salt Lake City next week, you are welcome to drop by JetBrains booth there for a live chat on TeamCity, YouTrack or other JetBrains products.
Friday, July 8, 2011
TeamCity 6.5.2: Fixes, Fixes, Fixes
Here is the build to upgrade your servers. Almost nothing really new, just fixes and several minor improvements mostly drived by your valuable feedback. See the report from the issue tracker for details.
The build uses the same data format as 6.5 and 6.5.1, so you can downgrade to 6.5.x if you need (but you hopefully do not).
BTW, if you have not yet checked recent update of JetBrains YouTrack to version 3.0, you might want to give it a try (free edition included). YouTrack team is also starting with YouTrack hosted offering, which definitely deserves a try if you need something lightweight yet powerful for your next project.
Like hosted YouTrack and want the same for TeamCity?
That's not something that we are already preparing while we do think about it.
We would really like to hear real-life stories why you need this and for what type of projects.
The build uses the same data format as 6.5 and 6.5.1, so you can downgrade to 6.5.x if you need (but you hopefully do not).
BTW, if you have not yet checked recent update of JetBrains YouTrack to version 3.0, you might want to give it a try (free edition included). YouTrack team is also starting with YouTrack hosted offering, which definitely deserves a try if you need something lightweight yet powerful for your next project.
Like hosted YouTrack and want the same for TeamCity?
That's not something that we are already preparing while we do think about it.
We would really like to hear real-life stories why you need this and for what type of projects.
Wednesday, June 8, 2011
TeamCity 7.0 Features Discussion: Agent Pools
Apart from maintaining 6.5.x branch and addressing critical issues there, we are preparing for a jump into 7.0 features and spend quite a time elaborating general directions and specific features. We will surely start presenting them within upcoming EAP releases.
There is one of the minor features I'd like to ask your feedback for at this time. It is a so-called Agent Pools: ability to manage assignment of build configurations to agents not only on agent level, but for a set of agents. This is necessary to reduce configuration effort.
Apparently, this is only an issue for installations with many agents, but we get a continuous flow of related requests from many customers.
Current idea that we want to start with is:
Allow creating an "agent pool" that will hold a set of agents. Each agent can belong to a single pool only. There is a default pool of agents that all agents initially belong to.
A pool has a set of associated projects. This means:
a) the agent in the pool can only run the builds belonging to the associated projects;
b) the builds from the build configurations within the projects can only be built on the agents of the associated pools (a single project can be associated with several agent pools).
We will still preserve current ability to select build configurations that can be run on a specific agent.
Now the question for you: Does this approach sound like a major help in simplifying your agent management needs? Is restricting the granularity to project level is enough for your specific case?
Feel free to vote in the poll (to the right on the main blog page) or leave your comments.
There is one of the minor features I'd like to ask your feedback for at this time. It is a so-called Agent Pools: ability to manage assignment of build configurations to agents not only on agent level, but for a set of agents. This is necessary to reduce configuration effort.
Apparently, this is only an issue for installations with many agents, but we get a continuous flow of related requests from many customers.
Current idea that we want to start with is:
Allow creating an "agent pool" that will hold a set of agents. Each agent can belong to a single pool only. There is a default pool of agents that all agents initially belong to.
A pool has a set of associated projects. This means:
a) the agent in the pool can only run the builds belonging to the associated projects;
b) the builds from the build configurations within the projects can only be built on the agents of the associated pools (a single project can be associated with several agent pools).
We will still preserve current ability to select build configurations that can be run on a specific agent.
Now the question for you: Does this approach sound like a major help in simplifying your agent management needs? Is restricting the granularity to project level is enough for your specific case?
Feel free to vote in the poll (to the right on the main blog page) or leave your comments.
Subscribe to:
Posts (Atom)