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

Missed the webinar? No problem – the recording of our July 10 webinar, What’s New in TeamCity 2018.1, is now available.

In this webinar, Anton Arhipov showcases the major features of the latest release. He goes over the significantly reworked TeamCity Kotlin DSL and shows how projects can be set up programmatically, from just one settings file. The High Availability TeamCity setup with a read-only node installation is also explained. Finally, the revamped Docker support with the updated Docker runner is demonstrated, as well as the bundled Amazon S3 artifacts storage.

Q&A from the session

Kotlin DSL

Q: Where can I learn more about the language used for DSL?
A: The language is Kotlin: http://kotlinlang.org/.

Q: Is there a way to define meta-runners using Kotlin DSL instead of XML?
A: Not at the moment. They are present in repository as XML files. But the point of meta-runners is to provide the ability to reuse steps. In Kotlin you can write a function which defines the steps, so probably you don’t need meta runners there at all.

Q: Do existing settings and builds defined in the Kotlin language in TeamCity 2017.2 get automatically updated to the new version or is 2018.1 backward compatible with existing declared Kotlin build pipelines and settings?
A: They will continue working as before. Since this is code, manual changes should be done to migrate DSL to the new version. First of all, the package should be changed to v2018_1, then compilation errors should be fixed. The version in settings.kts should be changed too. Here is documentation on how to perform the migration: https://teamcity.jetbrains.com/app/dsl-documentation/jetbrains.build-server.configs.kotlin.v2018_1/index.html

Q: What would the TeamCity behavior be if we have a project configured in Kotlin with active branches and the snapshot dependencies are changed in settings.kts for a branch which is not the default branch (for example a feature branch which adds a new build configuration to the build chain, but isn’t merged to master yet)?
A: Before triggering a build chain in a branch, TeamCity already needs to know how this chain is configured. So it can take these settings only from the current project settings. It can’t load them from the branch. So snapshot dependencies are always taken from the current project settings (basically, loaded from the default branch of the settings VCS root).

Q: Is there support for subprojects in Kotlin DSL?
A: Yes, there is.

Q: Can we specify the checkout rules for VCS builds?
A: Yes, you can specify all the same setting that you have in the TeamCity web interface.

Q: Can I use this settings.kts file and execute the steps locally on dev environment to mimic TeamCity?
A: Unfortunately, not. The DSL generates configuration, it does not execute anything. It generates new config files, which are applied to the project and then you can run builds with new settings.

Q: How the plugin details /settings are configured in settings.kts file?
A: All the settings can be configured by supplying a set of text properties: everything which can be configured in the TeamCity settings XML can be done via the DSL. Plugins can also provide typed API to DSL to get DSL completion for their settings configuration.

Q: Do we have a stages-like model similar to Jenkins?
A: The pipeline in TeamCity is declarative, not imperative. You define a set of configurations combined by dependencies. The server decides how to execute this pipeline, in which order, etc. Depending on the settings, requirements, available agents.

Q: Can we define different snapshot and artifact dependencies in different branches?
A: You can store different settings.kts files in different branches and create different projects from them. But in a single project, you can’t have a different set of configurations or different dependencies.

Q: Can the build configuration differ per branch or is it always loaded from the default branch? For example, can pull requests also build with a new configuration?
A: By default, server loads settings from the branch specified in the VCS root. It is possible to configure the server to load settings from the branch where the build is executed, but there are limitations. You can’t for instance, have a different set of projects or build configurations, as well as different snapshot dependencies.

Read-only node

Q: Data directory can contain certificates/ssh keys – is that not a risk of adding in NAS?
A: Data directory contains all the settings necessary to access the repositories, the data should be protected with due permissions.

Q: Is there a license cost for a read-only TeamCity server?
A: No, you can run the read-only node without any extra licenses.

Anton ArhipovAnton Arhipov is a Developer Advocate for TeamCity at JetBrains. His professional interests include everything Java, but also other programming languages, middleware, and developer tooling. Java Champion since 2014. Anton is also a co-organizer of DevClub.eu, a local developers community in Tallinn.
Posted in Features, Webinar | Tagged | 2 Comments

What’s New in TeamCity 2018.1, July 10th Webinar

Join us Tuesday, July 10th, 5:00 PM – 6:00 PM CEST (11:00 AM – 12:00 PM EDT) for our free live webinar, What’s new in TeamCity 2018.1 with Anton Arhipov.

teamcity_webinar_What_s_New_in_TeamCity_2018_1

In this webinar, Anton Arhipov will showcase all the major features of the latest TeamCity 2018.1. We will go over the significantly reworked TeamCity Kotlin DSL and show how projects can be set up programmatically, from just one settings file. The High Availability TeamCity setup will be demonstrated using a read-only node installation. Finally, we will look into the revamped Docker support with the updated Docker runner, as well as the bundled Amazon S3 artifacts storage.

Space is limited, please register now. There will be an opportunity to ask questions during the webinar.

Register for the webinar

Anton ArhipovAnton Arhipov is a Developer Advocate for TeamCity at JetBrains. His professional interests include everything Java, but also other programming languages, middleware, and developer tooling. Java Champion since 2014. Anton is also a co-organizer of DevClub.eu, a local developers community in Tallinn.
Posted in Features, Webinar | Tagged | Leave a comment

TeamCity 2018.1 released: revamped Kotlin DSL, read-only server, new Docker runner, and bundled S3 integration

Please welcome TeamCity 2018.1 – the first major release for TeamCity this year! This version gives you significant improvements in Kotlin DSL, revamped Docker support, native integration with Amazon S3 for storing artifacts, and High Availability installation possibilities.

800x400_blogTC_2018_1_@2x

If you took part in our recent EAP (Early Access Program), you may have already heard of the new functionality this release has in store. If not, here’s a quick overview:

New TeamCity Kotlin DSL

  • Simple. The DSL format is now simpler and more readable. No more uuid or project IDs.
  • Single file. One settings.kts file is now all you need to describe the project settings.
  • Portable. DSL scripts are now server and project independent.
  • Create from URL. Just point TeamCity to the repository with the settings.kts file, and it will spin up projects and build configurations as described in code.

High-Availability setup

Set up a highly available TeamCity installation with the new read-only server mode. The read-only server has access to the database and the data directory, and in the event of the main server becoming unavailable, will accept all the requests and allow read access to the builds, artifacts, etc.

Revamped Docker support

  • The Docker wrapper now supports .NET CLI and PowerShell runners, allowing you to run those build steps inside a Docker container.
  • build, push, and other Docker commands are available directly in the new Docker runner, which replaces the old Docker Build Runner.

Amazon S3 artifact storage

Storing, uploading, downloading, and removing artifacts from S3 is now integrated natively and can be done via the TeamCity UI.

There is more to this release! Enforced settings, improvements in templates, ability to upload a trusted SSL certificate, and UI updates. See the detailed description of these and other features in the What’s new section in our documentation.

Also, sign up for our free live webinar on July 10th to see the new features of 2018.1 in action.

Download TeamCity 2018.1

Please check the Upgrade Notes before you install the new version, and do not hesitate to report any issues in our tracker, or ask questions in the forum.

Happy building!

Posted in Features, Release | Tagged | 2 Comments

Welcome Jaipur 2018.1 RC

Today we’re announcing TeamCity 2018.1 release candidate.

This build contains over 150 fixes, improvements in support for Docker, but most importantly it comes with simplified Kotlin DSL format for TeamCity settings.

If you ever wanted to try Kotlin DSL for TeamCity settings but you were put off by its complexity, now it’s time to change your mind, as we considerably reworked it.

Remember that TeamCity RC build comes without the EAP license, but you can still use the license for the previous EAP release.

Check out our release notes, download Jaipur 2018.1 RC build, make sure to install it on a trial server: TeamCity 2018.1 will modify the data format and the downgrade is not supported.

Your feedback is always welcome in our forum or tracker.

Stay tuned for the latest news – the release date is approaching!

Happy building!

Posted in EAP, Release | Leave a comment

Rust plugin for TeamCity

Rust is an interesting programming language with decent tooling support. Cargo is an official build tool and a package manager for Rust programs. So what if you use Rust and want to configure automated builds in TeamCity? No worries, we have it covered! You can download the Rust and Cargo support plugin and install it as an additional TeamCity extension.

The plugin is compatible with TeamCity starting from version 10. It relies on rustup for managing the Rust toolchain.

The plugin detects the Cargo.toml configuration file once you add a VCS root to the Build Configuration, and suggests the corresponding build steps.

For the Cargo build step, it is enough to define just the name. However, multiple additional options are available under the “Show advanced options” link. For instance, it is possible to specify which packages and features the step should include, and which toolchain version should be used.

During the step execution, the plugin monitors the console output of the command. The summary is then displayed in the TeamCity UI: which tests were executed, how long it took every individual test to run, which tests were ignored, etc.

You can now build Rust programs with TeamCity and feel good about it! The plugin sources are available in the  GitHub repository and we are happy to receive your feedback in our forum and tracker!

Happy building!

Posted in Blogroll | Tagged , , | Leave a comment

Jaipur 2018.1 EAP2 is here

We are proud to announce another TeamCity early access preview build, code-named Jaipur 2018.1 EAP2.

Perhaps one of the most interesting features of this EAP version is the read-only server, which makes High Availability setup possible with TeamCity. The read-only server allows users’ read operations: viewing the build information, downloading artifacts, etc. during the downtime of the main server. When the read-only server works side by side with the main TeamCity server, the read-only one constantly updates information about the builds, projects, users, and all other entities. Thus at any point of time it shows up-to-date information.

Other new features and improvements include:

  • the ability to upload a trusted HTTPS certificate
  • NuGet Feed at the project level, allowing different feeds for different projects and even more granularity with the ability to index packages published by builds of selected configuration only
  • the bundled Amazon S3 plugin which allows storing artifacts produced by agents in an S3 bucket and work with them as if they were stored internally
  • reworked TeamCity integration with Docker
  • the renewed user interface
  • other improvements, counting over 150 fixed issues in total.

See our release notes for details.

Download Jaipur 2018.1 EAP2 build, and remember to install it on a trial server: the new version changes the TeamCity data format and the downgrade is not possible.

As usual, this EAP release comes with a 60-day Enterprise evaluation license for an unlimited number of agents and build configurations: we’ll appreciate if you try this build and share your feedback in our forum or tracker.

Happy building!

Posted in Bugfix, EAP | 3 Comments

TeamCity 2017.2.4 is out now

Today we are announcing TeamCity 2017.2.4, a bugfix update addressing about 90 problems, including several performance and security issues. The comprehensive list of fixes is in our Release Notes.

We strongly recommend upgrading, which is especially easy within TeamCity 2017.2.x builds with automatic update. To upgrade from older versions, download TeamCity and follow our upgrade instructions.

TeamCity 2017.2.4 shares the data format with other 2017.2.x versions providing the ability to upgrade/downgrade easily.

Your feedback in our forum and tracker is always appreciated.

We are working on the new TeamCity 2018.1 version, so follow us for the latest news on the upcoming release.

Happy building!

Posted in Bugfix, Release, Uncategorized | Leave a comment

Deploying TeamCity into AWS using CloudFormation and Fargate

For the good cause, it is sometimes easier to start with TeamCity by deploying it into a cloud service, such as AWS. This allows the users to try TeamCity without the need to prepare the dedicated machine.

For the quick start, it is possible to use CloudFormation template which deploys the minimal setup to AWS. For the agents, TeamCity includes the integration for Amazon EC2 out of the box. However, there is also an alternative way to start the agents as Docker containers at Amazon’s Elastic Container Services platform.

In this article, we’re going to describe how to deploy TeamCity server using the CloudFormation template and how to configure the agents to run on Amazon ECS with Fargate.

Deploying TeamCity server to AWS with CloudFormation template

The official TeamCity CloudFormation template is available to simplify deployment to AWS. The resulting implementation will start a VM with two Docker containers: one for TeamCity server, and the other for the default agent.

DISCLAIMER: The current configuration of the CloudFormation template is not recommended for production setup. The default agent is configured to run on the same machine as the TeamCity server. Instead, it is advised to run the agents separately in order not to consume the machine resources required by the server.

Deploy TeamCity to AWS using CloudFormation template

Once a TeamCity server is deployed, check the Outputs tab for the URL. After the initial configuration steps, it is possible to add more build agents to the server. There are multiple options for TeamCity agents deployment at AWS. In the following, we’ll describe how to deploy the agent to Amazon ECS with Fargate.

AWS Fargate for TeamCity Agents

AWS Fargate is a technology for Amazon ECS that allows us to run containers without having to manage servers. TeamCity agent can be deployed as a container to ECS by using Fargate.

The short-lived container instances at ECS are perfectly suitable for executing build tasks. For TeamCity, it means that it is possible to acquire more resources dynamically. Once more agents are required to process the build queue TeamCity will request a new agent to start via Fargate. The agents can stop once the workload isn’t as high anymore.

To run TeamCity agents at Amazon ECS with Fargate several steps needs to be fulfilled:

  1. Have a running TeamCity server instance
  2. Install the required plugins for TeamCity server
  3. Create task definition for TeamCity agent in Amazon ECS
  4. Create cloud agent profile for the project in TeamCity
  5. Optionally, configure S3 artifact storage for the project in TeamCity

Installing Plugins

The required integration with various AWS services activates by installing the additional plugins to TeamCity server. To make use of AWS Fargate integration in TeamCity the Amazon ECS Support plugin needs to be installed. Also, one might want to consider storing the build artifacts in Amazon S3 as well. AWS S3 Artifact Storage plugin enables the integration.

Once the plugins are installed, we can proceed to the configuration.

Agents Configuration

Create AWS Fargate task definition

TeamCity agent is available as a Docker image via Docker Hub. In the Fargate task definition, it is possible to define a container, referring to that image. Once the server requests for a new agent via Fargate, a new container will start on Amazon ECS.

The important bit is to add SERVER_URL environment variable pointing at the URL of the TeamCity server. The agent will use that variable to connect to the server.

Create Fargate task definition

Create cloud profile for a project in TeamCity

To enable cloud integration in TeamCity one has to create a cloud profile for the desired project. Configuring cloud profile in TeamCity is quite straightforward.

Go to the project settings, the Cloud Profiles tab, click “Create new cloud profile” button and proceed with the configuration. Make sure to select Amazon Elastic Container Service as the cloud type.

It is also important that the selected AWS region in the cloud profile matches the region that you used to create the Fargate task definition.

In order to point the cloud profile at the task definition in Farget we have to add an agent image with the appropriate launch type.

Create Fargate task definition

Artifact Storage Configuration

In TeamCity, a build configuration can expose the resulting artifacts. It is wise to store the artifacts in the external storage. We can use Amazon S3 to save the files. Let’s see how to configure the service for TeamCity.

In the project settings, navigate to the Artifacts Storage Project tab and click the “Add new storage” button. Select “S3 Storage” type and fill in the name, bucket name and press Save. After that, activate this artifact storage in the TeamCity project by clicking the “Make Active” link. The new builds in this project will store artifacts in S3 automatically.

S3 artifact storage configuration

Summary

TeamCity was designed as on-premise solution. However, cloud services, such as AWS, simplify the setup if you would like to try TeamCity for your projects. It is easy to start with the CloudFormation template and scale by deploying the agents as Docker containers at Amazon ECS.

Posted in Blogroll, Features, How-To's | Tagged , , | Leave a comment

BitTorrent Plugin for TeamCity

Some time ago we announced the plugin that turns TeamCity into a torrent tracker and a seeder for large artifacts.

Judging by the flow of feedback — both positive and not so much — the plugin is in use by quite a few of our users. To remedy the not-so-much part, we are presenting a new version of the plugin, BitTorrent Support, today.

Plugin changes

If you’re new to BitTorrent, you might want to read our previous post on the subject first. For those familiar with the plugin, here is the list of the critical performance and security bug fixes, as well as the new features:

  • Optimized downloading speed in the torrent library (TW-49963)
  • Optimized memory usage by seeded torrents on the server and agent sides (TW-35395)
  • Optimized server resource usage on a build finish
  • Security fix related to modifying torrents settings by non-server admin users (TW-9523)
  • Ability to switch the plugin on/off for particular projects and build configurations
  • A large number of minor fixes.

Setting up the plugin

The new BitTorrent Support plugin is compatible with the latest TeamCity 2017.2.x+. Download the plugin from the JetBrains plugin repository and install it as usual.

Once you restart the server, a new link, Torrent Settings, will appear in the Administration area. By default, the plugin is disabled. To enable it server-wide, check the options for the TeamCity server and agents (you can later disable the plugin for some of the projects or build configurations if required):torPlugSettings

For the plugin to work correctly, TCP ports in the 6881-6889 interval should be open on the TeamCity server and agents.

If the plugin works correctly and you checked the options on the Torrent settings page, in the subsequent builds the agents will use the BitTorrent protocol to download all large artifacts (over 10Mb by default). The details will be logged: see the example of the build log in the Verbose mode:

Users can also download artifacts from the server via the BitTorrent protocol. To download a torrent file, click the torrent icon near the artifact name:torPlugArtDownload

Enabling / disabling the plugin for particular projects and build configurations, as well as controlling the artifacts size available via BitTorrent can be done using the configuration parameters described in the technical notes to the plugin’s Github repository.

Try the new plugin version and let us know what you think in the comments to this post, in our in our forum or tracker.

Happy building!

Posted in Blogroll, Features, FYI | Leave a comment

TeamCity 2018.1 (code-named Jaipur) EAP is open

Today we are opening the early preview program (EAP) for TeamCity 2018.1.
It’s been a tradition with us at TeamCity to name our versions after cities in India, so please welcome Jaipur 2018.1 EAP1.

This version will definitely be interesting for our customers using build configuration templates: you can now define build steps common for build configurations and place these steps before / after the build configuration’s own steps, conveniently using a placeholder for the latter.

Another thing is that now TeamCity allows more flexibility when it comes to redefining settings inherited from a template – now it is possible to change every setting of the inherited build step without the need to introduce parameters in the template. On the other hand, if you are a system administrator and if you want to enforce some settings on all the build configurations in the project so that other users could not redefine them, TeamCity now allows you to do this too.

Other improvements touch on the TeamCity integration with Docker, shared resources, our UI pages and much more, including over 70 fixed issues: see our release notes for details.

Download Jaipur 2018.1 EAP1 build, and remember to install it on a trial server as the new version changes the TeamCity data format.

All our EAP releases come with a 60-day Enterprise evaluation license for an unlimited number of agents and build configurations, and we do hope that you’ll try this build and share your feedback in our forum or tracker.

Happy Easter and happy building!

Posted in EAP, Features, Release, Uncategorized | 2 Comments