TeamCity Project- and Build-Configuration in Code

For some time now the CI/CD tool TeamCity is able to configure builds by writing code and providing it in a repository like git along the production code.

These settings can even be synchronised between the interactive frontend and the code.

With the introduction of the "Portable Kotlin DSL" in der Version 2018.1 the feature became even more interesting.

This talk introduces some basic concepts and invites you to start experimenting by providing a simple project on GitHub.

Transcript

1. Alexander Sparkowsky | info@roamingthings.de | 28.02.2019 TeamCity Project- and Build-Configuration in Code
2. Alexander Sparkowsky | info@roamingthings.de | 28.02.2019 What? • Project- and build-configuration in code with TeamCity • Implementation vs. UI interaction
3. Alexander Sparkowsky | info@roamingthings.de | 28.02.2019 Why? • Repeatable • Reusable • Documentation • Versioning/transparent • Configuration close to productive code • Dynamic configuration for example depending on parent project • Testability
4. Alexander Sparkowsky | info@roamingthings.de | 28.02.2019 Formats • XML • Part of TeamCity for a long time • TeamCity 10.0: Non-Portable Kotlin DSL • Introduction of a Kotlin based DSL for build configuration • Type-safe • IDE friendly • TeamCity 2018.1: Portable Kotlin DSL • Much simpler syntax • Reusable (portable) configuration
5. Alexander Sparkowsky | info@roamingthings.de | 28.02.2019 How to setup a project? • Green field: • Implement the script from scratch • Let TeamCity do the work: • Create your build configuration using TeamCity • Activate versioned settings or download generated project files
6. Alexander Sparkowsky | info@roamingthings.de | 28.02.2019 How to integrate? • Add it to the same repository as your code inside a .teamcity folder • Separate repository for build configuration
7. Alexander Sparkowsky | info@roamingthings.de | 28.02.2019 Settings Synchronisation • Use versioned settings pane in TeamCity project • Priority: repository/TeamCity/no priority • Script will be compiled and executed on repository changes • Changes on the build configuration are applied in parallel to the regular build chain execution
8. Alexander Sparkowsky | info@roamingthings.de | 28.02.2019 Apply Settings to Project • Existing project: • Versioned settings
 pane
 • New project: • TeamCity recognises .teamcity/settings.kts and asks when repository is imported • Activate synchronisation after project setup
9. Alexander Sparkowsky | info@roamingthings.de | 28.02.2019 Project Structure • .teamcity-folder • pom.xml • Imports required dependencies to enable code completion etc. • settings.kts • Entrypoint for implementation
10. Alexander Sparkowsky | info@roamingthings.de | 28.02.2019 Build-Ids • Are generated automatically by concatenating with the id of the parent:
 id(“MyBuildStep”)
 <parent-id>_MyBuildStep • Beware of maximum id length
11. Alexander Sparkowsky | info@roamingthings.de | 28.02.2019 Apply Changes • In code: • Update the script • Commit & Push • Interactively: • Make changes in the TeamCity frontend • Use View DSL to view and learn about the generated DSL
12. Alexander Sparkowsky | info@roamingthings.de | 28.02.2019 Patching • Changes in the TeamCity frontend creates “patch” scripts: /* This patch script was generated by TeamCity on settings change in UI. To apply the patch, change the buildType with id = 'Build' accordingly, and delete the patch script. */ changeBuildType(RelativeId("Build")) { expectSteps { gradle { tasks = "clean build" buildFile = "" gradleWrapperPath = "" } } steps { update<GradleBuildStep>(0) { name = "Build the project" } } }
13. Alexander Sparkowsky | info@roamingthings.de | 28.02.2019 Dynamic Configuration • Configuration-parameter in parent-projects • Use inheritance • Apply regular expression syntax in strings
 “build -P%myVar%” • Dynamic triggers and build-types • Use regular Kotlin code in the script to add build-types, triggers etc. • Everything has to be done in code! No access to resources/files.
14. Alexander Sparkowsky | info@roamingthings.de | 28.02.2019 Links TeamCity product page
 https://www.jetbrains.com/teamcity Kotlin DSL API documentation
 http://build.bitcoinabc.org/app/dsl-documentation/index.html TeamCity documentation
 http://confluence.jetbrains.com/display/TCD18/Storing+Project+Settings+in+Version+Control
 http://confluence.jetbrains.com/display/TCD18/Kotlin+DSL
 http://confluence.jetbrains.com/display/TCD18/Managing+Projects+and+Build+Configurations Workbench-project
 https://github.com/roamingthings/teamcity-buildconfig-workbench
15. Alexander Sparkowsky | info@roamingthings.de | 28.02.2019 What to discover next • What about testing? • How to debug? • Add libraries to the settings projects? • Create libraries for reusable projects or use a separate repository?
16. Alexander Sparkowsky | info@roamingthings.de | 28.02.2019 Contact Alexander Sparkowsky
 info@roamingthings.de Twitter
 @fischbauch
 
 GitHub
 https://github.com/roamingthings Blog
 https://roamingthings.de