Take your automated CI/CD pipeline to the next level with configuration as code. Store and manage your TeamCity build configurations in version control for improved reusability, portability, maintainability, and consistency.
Efficiently replicate build logic across projects, apply updates to multiple configurations consistently, and manage your pipelines systematically.
Revert your build configurations to earlier versions easily.
Implement a peer review process for each update.
Control access to your pipeline logic.
Maintain an audit log of every change.
Choose between TeamCity Cloud and TeamCity On-Premises.
Make your VCS the single source of truth for build configurations and application code to unlock all the benefits of source control. With TeamCity, you can choose whether to synchronize changes made via the web UI to your version control system automatically or disable build configuration editing from the UI and require all changes to be made in code.
With Kotlin DSL, you get all of the benefits of a complete programming language coupled with the strengths of a DSL designed to build pipelines as code.
Access to every TeamCity build feature from an intuitive, statically typed language.
Define your own classes, functions, and libraries to write efficient and well-structured pipeline logic. Import functionality from external libraries.
Author your build configurations from IntelliJ IDEA and benefit from code navigation, autocompletion, syntax highlighting, and refactoring suggestions.
Configure sequential and parallel build chains with code that’s easy to understand. Preview the settings for a particular configuration from the TeamCity UI.
Using Kotlin brings a lot of advantages and makes configuring your pipelines easier than with YAML. It might seem intimidating at first, especially if you’ve never used Kotlin before, but it doesn’t have to be. To help you write configurations in Kotlin, TeamCity automatically generates DSL code for all of your settings and lets you preview it in the admin UI.
When you’re building and testing your changes across different platforms and with multiple versions of each framework or software development kit, the number of build configurations multiplies quickly. By managing those configurations as code, you can reuse scripts and encapsulate settings in just a few lines of code.
With TeamCity’s Kotlin DSL, you can streamline your pipeline configuration into code that is easy to reuse and maintain, giving you the power to update settings for every build job in just a few seconds.
“Our policy is to disable editing in TeamCity’s UI. One of our goals is to standardize pipelines. We achieve that by using configuration as code. All build configurations are stored in their respective repositories as Kotlin code. We’ve built our own DSL on top of the TeamCity Kotlin DSL, which allows us to define pipelines using 20 lines of code or fewer.”
– Ivan Babiankou, Staff Software Engineer, Picnic
Kotlin DSL in TeamCity comes with clear, extensive documentation that you can rely on to set up your projects. Simply copy-paste the examples from the documentation directly into your codebase so you always know what function to use next.
With configuration as code for your CI/CD pipelines, TeamCity brings you another step closer to the DevOps goal of continuous feedback and improvement. Whether you’re modifying settings from the TeamCity UI or only making code changes, each update to your pipeline can be put through a series of manual checks and automated tests before it is deployed.
Not sure if TeamCity is right for you? Contact us and we will tell you more about configuring your projects as code in TeamCity or schedule a demo session.
Configuration as code is a well-established practice for CI servers. The benefits of this approach include versioning support via a VCS repository, a simplified audit of the configuration changes, and improved portability of the configurations. Some users may also prefer code to point-and-click configuration via UI.
As a concept, it might be better to configure the build using code rather than in the UI. You can store code in a repository and have more control over the changes, roll back to previous versions, and see the change history. It’s also easier to maintain and transfer settings as code rather than reconfigure everything in the UI.
There are several ways of storing configurations as code. TeamCity supports 2 of them: XML and Kotlin DSL.
The Kotlin DSL provides several advantages over XML for configuring your project settings as code:
Powerful CI/CD for teams that store their project configurations as code