Teamcity Introduction

All projects are built and deployed by our teamcity build server. You should be able to access all your gitlab projects in teamcity as well. Have a look at it, it is very useful for development as well. E.g. errors during the build are available here.

Usage

Best open up a teamcity browser tab while reading this.

Projects

Teamcity organizes data into projects. Projects can have subprojects and build configurations. Our instance reflects the tree structure of the Gitlab VSETH Group into teamcity. So every gitlab group and project becomes a teamcity project.

Build configurations

Every teamcity project which corresponds to a gitlab project has one build configuration called "SIP" (this is mainly due to gitlab only being able to interact with one TC build configuration). A build configuration specifies what happens during a build. So every build is an execution of a build configuration.

Once you open teamcity, you are in the "Project Home" view. Here you see projects, build configurations, project branches and builds. Just look around a little. Try to open a build and view the build log of it.

If you want to see the configuration of a project or build configuration, in the top right there is a link "Edit (Project|Configuration) Settings". Click it to view the settings. In the project settings you mainly see project-level parameters and more importantly the "SIP" build configuration. Go there. In the build configuration settings you see the concrete build steps being performed (also see below), dependencies of the project (e.g. they all depend on servisctl), when to trigger a build (managed automatically) and much more. Just look around a little

Permissions

The Permissions on the Teamcity server are synchronized every 1 hour from the Permissions that you have on the Gitlab projects. The mapping can be found Teamcity Permissions. After your initial login to the server you have to wait 1 hour for the permissions to synchronize, because the permissions are only synchronized after your user has be created after the initial login.

Build steps

All docker image projects are built using the same steps in order:

Book-keeping:

• Base image registration: The project is connected to all its base images to ensure it is rebuilt on base image updates

Deploying:

• servisctl pull gets the latest proto files for the application according to the apis listed in sip.yml
• docker builds the image according to the Dockerfile
• docker pushes the built image to our registry
• SIP application publishing: The SIP application in the kubernetes cluster is updated according to the content of the sip.yml