Best practices/Design Patterns planning CI CD using team city

tl"dr

Im looking for training for someone who is comfortable with team city on how to design flows. preferably for SAAS MicroServices architecture with CD.

 

I use TC for several years now.

but I'm still not clear on what is the best way to build an easy to maintain scalable projects in team city. 

for example should I have separate configuration for main steps in the build?

the current project structure has a main Project with 5 build configuration templates. and dozens of subprojects.

99% of the projects have extacly the same 5 configurations (inherited from template) each inheriting form a diffrent template.

all the subprojects are clones of each other. and adding a new configuration step to all subproject is an insane manual job 

 

how can I force all subprojects to inherit the same configurations/order.

 

my configurations stand for major build steps

build

unit test

integration test

reporting

artifact publishing

 

maybe they all should be on seperate projects?

 

ie instead of each service having 5 configs I should have 

Build Project

Test Project

Integration Project

Deploy Project

..

and have each flow run between projects?

 

2 comments
Comment actions Permalink

Hi Nahum,

thanks for your request. Templates are stored at the project level, so if all build configurations inherit from the templates (which since 2017.2 you can force through the use of default templates), adding a step should just be a matter of modifying the build template, so adding steps shouldn't be any titanic task.

Regarding on split configurations or steps. It's important to keep track of what each component means. Build configurations are units of work that should be handled together as a whole. They can be a full build or they can be just a part of it, they can have multiple or single steps, but the important part is that they are executed as a whole in a single agent, following the defined steps. Also important is that multiple configurations can be run in parallel in multiple agents, so a split of a "full build" in multiple configurations can make sense in order to parallelize tasks. Separating a build in multiple configurations to later force them to run on the same agent creates a maintenance overhead and uses more resources, so it should be doing mindfully.

Projects are mostly a UI Tool to provide organization and inheritance of utilities, such as parameters, variables, meta runners or templates. Another goal of projects is to separate permissions from users who shouldn't have access to some projects.


With all this in mind, there is a last point that should make all this substantially easier. Since 10.0 TeamCity offers the Kotlin DSL as a method to generate projects and build configurations. While the XML format was around earlier, the XML format requires to manually modify each xml file which is not particularly comfortable. With Kotlin being compiled on the server in order to generate the XML files, it allows for dynamic modifications, code generation, etc. which means that it should be much easier to handle large amounts of copies of similar items. We have an introduction in our blog with similar examples to those in your situation: https://blog.jetbrains.com/teamcity/2016/11/kotlin-configuration-scripts-an-introduction/

0
Comment actions Permalink

Regarding templates in TeamCity: It is our experience that moving to Kotlin removes the need for using templates. It is more flexible to code those templates in Kotlin instead, which removes many of the limitations that templating has.

Environment specifc details should be kept out of Kotlin, using Groovy scripts to provide environment specific parameters seems to be a working solution.

0

Please sign in to leave a comment.