TeamCity and Plastic SCM: Full-Blown Automation to Deliver Faster and Better

This guest post is brought to you by Jordi Mon Companys, the Product Manager of Plastic SCM.

plasticscm_logoPlastic SCM is a full version control stack for all things DevOps. It’s an enterprise-ready, DVCS and CVCS for teams any size with built-in branching and merging engines to enable collaboration, pipeline automation, and project shipping. The perfect tool to rapidly deliver well-designed software.

Continuous Delivery is one of the most effective approaches to developing high-quality software, and TeamCity’s success is a clear example. For a company that builds a version control system like we do, thinking of CI as a process to develop software may sound weird at first. Initially, we could argue that TeamCity belongs to the deploy part of the software lifecycle. But the reality is that advances in the Ops side of this lifecycle have influenced greatly how the initial phases of a software project are conceived, and therefore its tooling. As a company devoted to making the life of our users easier, Plastic SCM is providing the means for its clients to use TeamCity seamlessly.

Códice Software products and JetBrains products have a long history of integrations. Both companies have always understood the value of providing tight-knit connectors that allow users to deliver quality software to their customers. Plastic SCM is Códice Software’s flagship product: a full version control stack with cross-platform GUIs, branching and merging superpowers and more. It solves many software development riddles in a comprehensive and versatile way. TeamCity stands on the Ops side of this software lifecycle, making both tools a perfect combination for modern day DevOps.

Alpha and Omega: from source control to CI

The main outcome of this DevOps setup is that TeamCity now acts as an integrator, taking an active role in the development and automation of the merge process. Getting better and faster to the market than your competitors is by definition good. Reacting to business needs and change is also part of this approach. Thus, having source control connected to a powerful CI system is the best choice for your pipeline to fulfill these and other goals.

Connecting TeamCity and Plastic is easy. Plastic SCM developed a plugin available here (Editor’s note: the plugin comes bundled with Plastic SCM and can be installed during the setup process). Once the VCS Root is configured in the Edit Build Configuration panel, the following four steps should be performed:

1. Select Plastic SCM as your version control

choose-vcs-root2. Choose the correct server and repo and select the branches TeamCity will monitor

server-and-branches3. Attribute new branch filtering


A step by step branch per task example with auto merging

This is how a development cycle looks with TeamCity merging branches to main automatically when a certain attribute is set.

Plastic – Create new branch

First, a new branch named DTC-14 is created to fix task 14 in the associated issue tracker.


Plastic – Apply attribute

Next, work is done on the branch and a few changes are made to get the task fixed. Once done, mark the branch as resolved by setting a status attribute to it.resolved

TeamCity – Monitoring

TeamCity is continuously monitoring the repo, so DTC-14 is detected and since it matches the filter conditions, it is selected to be built and merged.


TeamCity – Status

Everything went fine for task branch DTC-14, and the TeamCity status reflects it.


Plastic – Branch merged to main

Once the build is ready, Plastic SCM’s plugin for TeamCity triggers the merge to main. DTC-14 is now merged to main, and its status attribute was updated to merged. All this has been performed by TeamCity.merged


With this setup, TeamCity will act as a mergebot taking an active role in the development and automation of the merge process. From then on, TeamCity will run builds and tests. If no conflicts arise, it is merged to main and a build is released promptly.

More than technicalities: high-performance team culture

Eventually, our clients have experienced the freedom to experiment with ideas and products. This goes beyond tooling: companies that have the appropriate toolset can focus on change, efficiency and software quality which is, after all, what drives value to their customers and growth to their company.

In the end, Plastic SCM and TeamCity’s integration enables the worlds of software development, deployment, product management, QA and so on to converge and deliver its best. These integrations are providing the underlying toolset of the best software development methodologies.

Posted in Guest post, Partner | Tagged , , | 3 Comments

Welcome TeamCity 2019.1 EAP1

We’re excited to announce the Early Access Preview (EAP) for TeamCity 2019.1. Following the tradition, this release is code-named after a gorgeous busy Indian city called Kanpur hinting at elegance and efficacy being the highlights of the upcoming version.

Kanpur 2019.1 EAP1 comes with the revamped user interface and we’re hoping that your experience with TeamCity will now be not only more productive but also aesthetically pleasing.

Our UI comes with a new sidebar, the reworked branches tab, expandable build rows, and the redesigned project overview page. It is still considered experimental, and some pages are not yet available, but you can easily switch between the new and classic UI using the icon in the right-hand upper corner of the screen.


Another important feature of this version is the ability to cancel a build from a script using a service message. If needed, you can re-add the build to the queue after canceling it:

##teamcity[buildStop comment=‘canceling comment’ readdToQueue=‘true’]

The detailed feature description and the list of fixes are available in our Release Notes.

As usual, the new release changes the TeamCity data format and, since version 2019.1 is still in development, we recommend installing it on a trial server.

You are welcome to try the new EAP build and share your feedback on our forum or tracker.

Happy building!

Posted in EAP, Features, News & Events | Leave a comment

TeamCity 2018.2.2 is released

TeamCity 2018.2.2 is out today. This bugfix update addresses about 80 issues and brings a number of back-end and front-end performance improvements.

We strongly recommend upgrading as this TeamCity version resolves a few security problems as well. The full list of fixes is available in our release notes.

Like any TeamCity update, 2018.2.2 has the same data format as all 2018.2.x versions, allowing you to upgrade/downgrade within these builds easily.

Remember to check our Upgrade Notes and use one of the upgrade options:

Your feedback is always welcome in our forum or tracker.

Happy building!

Posted in Bugfix, Release | Tagged | 3 Comments

New in TeamCity 2018.2: Simplified Installation of Plugins

Installing new plugins has just become a lot simpler! You don’t have to restart the server to enable a newly uploaded plugin anymore.

The TeamCity server now integrates with the JetBrains Plugins Repository. The new integration simplifies the installation of plugins for TeamCity.

By clicking the “Browse plugins repository” button in your TeamCity server, you will share some information (URL, server id, and version) with the plugin repository. With this information, the plugin repository is able to suggest installing the selected plugin version directly to your TeamCity server. The screencast below demonstrates the plugin installation procedure.

Aside from this, if you have disabled some of the bundled plugins on your TeamCity server, enabling them also does not require a server restart.

It is also possible to enable a periodical check for plugin updates on your TeamCity server. Once any updates are found in the plugin repository, they can be easily installed through the web interface. However, you’ll still need to restart the server to apply the plugin updates.

Aside from this, if you have disabled some of the bundled plugins on your TeamCity server, enabling them also does not require a server restart.

It is also possible to enable a periodical check for plugin updates on your TeamCity server. Once any updates are found in the plugin repository, they can be easily installed through the web interface. However, you’ll still need to restart the server to apply the plugin updates.


Finally, there is good news for TeamCity plugin developers. If you develop your plugins with the help of our Maven SDK or the Gradle plugin by Rod MacKenzie, you can benefit from reloading plugins without restarting the server. In addition to this, when TeamCity is started from these SDKs, it will work in a mode where the plugins can be enabled or disabled instantly, also without the need for a server restart.

Posted in Blogroll, Features, Tips&Tricks | Tagged , | Leave a comment

New in TeamCity 2018.2: Show Kotlin DSL for Build Configurations

The Kotlin-based DSL is becoming more popular for defining build configurations in TeamCity. We are continuing to improve the user experience for Kotlin, both in the TeamCity UI and the IDE plugin.

Once the versioned settings option is enabled for the project, we recommend making new changes in the Kotlin configuration rather than in the UI. However, it might be tempting to make the changes in the UI instead of figuring out how to define something in Kotlin. For such occasions, we have added a little UI helper to assist with the DSL definitions.


TeamCity 2018.2 introduces a new option in the UI to help anyone who uses the Kotlin DSL. You will find the new “View DSL” toggle in build configuration settings in the UI. Click the toggle to view the Kotlin DSL definition. The DSL representation opens and highlights the setting in focus.


Check out the screencast demonstrating the new feature in action:

Posted in Blogroll, Features, Tips&Tricks | Tagged , | Leave a comment

Webinar recording and Q&A: What’s New in TeamCity 2018.2

Missed the webinar? No problem – the recording of our January 8 webinar, What’s New in TeamCity 2018.2, is now available.

In this webinar, Anton Arhipov showcases the major features of the latest release. He goes over the secondary node setup and explanation, building GitHub pull requests, showcases the simplified installation of plugins, previewing Kotlin DSL configuration in the UI, automatic assignment of investigations, and metadata in tests.

Enjoy watching and feel free to share with your friends and coworkers.

Q&A from the session

Q: Can secondary server node feature be used for migration to another server (add secondary, remove primary)?
A: Read-only (available in 2018.1 already) node can to some extent. We also plan to cover the use case when further extending the multi-node setup.

Q: The example shown for secondary nodes had both servers running on the same computer. Is this required, or can the secondary node be on a different system? And if it can be different, can it be on a different OS (Linux/Windows, etc.)?
A: They can be installed on different machines. Different OSes are also supported. It is required to share the data directory somehow (Windows SMB or Linux NFS will work). Still, it makes sense to have the same OS for both servers to simplify the setup.

Q: Does the Agent and/or Server restart when installing new plugins?
A: The server loads the plugin without restart. Since this plugin brings in an agent part, that agent part is automatically downloaded by all the agents and the agents are restarted automatically. This agent update just takes some time.

Q: When an Agent restarts, is it rebooting the machine or stopping and starting the TeamCity agent service?
A: Only the TeamCity agent service is restarted. The Agent restarts and updates without the whole machine restart.

Posted in Features, Webinar | Tagged , , , , | Leave a comment

New in TeamCity 2018.2: Metadata in Tests

Ever since TeamCity 2018.2, a test run in TeamCity can be associated with some supplementary information (metadata), in addition to a test’s status, execution time, and output. This information can be used to provide things like extra logs, screenshots, numeric values, and tags.

You can now use service messages to report this kind of additional test data in TeamCity and then view it using the TeamCity Web UI. Consult the corresponding documentation for details.

On GitHub, you can find a sample project that demonstrates the use of metadata with tests. In TeamCity, create a project from the URL using this GitHub repository, and then run the build. Once the build completes, on the Tests tab, next to the test name, you will notice a paperclip icon indicating that the test results include additional metadata.


By clicking the icon, you will open a popup displaying the attached metadata. The same information is presented on the build overview screen. Notice that a numeric value renders a 2D-graph from the historical results.


In the demo project, see CodeTest.kt for the examples of the metadata reporting code.

Posted in Blogroll, Features, Tips&Tricks | 5 Comments

New in TeamCity 2018.2: Increased Scalability

TeamCity 2018.1 allows you to set up a “running builds node.” The node handles data coming in from the build agents. There’s also the “read-only node” for handling disaster recovery scenarios.

TeamCity 2018.2 expands this setup further, making it possible to delegate polling of version control systems to a secondary node.

Currently, it may seem a little complicated, but our intention is simple. We want to have a scalable architecture where you can add more nodes to the cluster so that all the nodes are uniform and can perform all the tasks in an interchangeable way. The only exception will be the main TeamCity server where we configure the cluster. Upgrade, licensing, and diagnostics are also handled by the main TeamCity server.

As a step towards this uniformity, there is no “read-only node” anymore, and it is now called a “secondary node.”

The secondary node is just a TeamCity server started with the additional nodeId argument:
TEAMCITY_SERVER_OPTS=-Dteamcity.server.nodeId=<some id> teamcity-server.bat|sh start

See our documentation on how to configure and start a secondary node.


By default, the secondary node acts as a read-only node. It does not change any data, but only shows the user interface in read-only mode. This setup is well-suited for disaster recovery tasks.

Using the Nodes configuration page of the main TeamCity server, it is now possible to delegate VCS repositories polling responsibility to this secondary node. After that, the secondary server will handle all VCS polling related tasks and commit hooks. In some scenarios, this can greatly reduce the CPU load of the main TeamCity server.

Note that if there are existing commit hooks on the main server, you do not need to change anything. The main server will accept the hook and delegate its processing to the secondary node.

Right now, the secondary node cannot handle data from agents like the running builds node can. But this will change in the future versions of TeamCity. Agents’ data handling will be another responsibility for the secondary node.

Posted in Blogroll, Features | Tagged | Leave a comment

TeamCity 2018.2.1 is out

Today we’re announcing TeamCity 2018.2.1, a bug fix update for our recently released version.

This version fixes about 100 issues, most notably upgrade-related problems. Besides, LDAP authentication now works properly when a trusted certificate is added to the TeamCity server. Several important UI improvements have been made as well; the full list is available in our release notes.

We strongly recommend upgrading, as this build also addresses some TeamCity performance issues.

As usual, TeamCity 2018.2.1 update has the same data format as all 2018.2.x versions, allowing you to upgrade / downgrade easily within these builds.

Remember to check our Upgrade Notes and use one of the upgrade options:

We appreciate your feedback in our forum or tracker.

Happy holidays and happy building!

Posted in Bugfix, Release, Uncategorized | Tagged | 8 Comments

TeamCity 2018.1.5 is here

Today we’re releasing the TeamCity 2018.1.5, the last bug fix build for the previous TeamCity version.

Although TeamCity 2018.2 is already out, we’re rolling out this update as it addresses a few important issues; see all of them listed in our release notes.

As any TeamCity update, 2018.1.5 has the same data format as all 2018.1.x versions, allowing you to upgrade / downgrade within these builds easily.

Remember to check our Upgrade Notes and use one of the upgrade options:

We’ll appreciate your feedback in our forum or tracker.

Happy building!

Posted in Bugfix, Release | Leave a comment