Through the thorns to the assembly

Hello dear readers. I am a developer at RTL Service, in which my product development responsibilities overlap with DevOps. More specifically, I create and maintain the infrastructure of the assembly and initial testing of our products before they enter the testing department.

This article will tell you what path the code goes from pushing the repository of the version control system to generating the deb package and placing the packages into our repository.

As a CI server (continuous integration), we use Hudson, you can throw slippers at me, but we are guided by the principle “It works - do not touch”. In the future, there are plans to try TeamCity or Jenkins.

General information about tasks and groups on our CI server.

All tasks for assemblies are divided into 5 large groups:
● Firmware (device firmware build, they are beyond the scope of this article, but the first and second build steps are the same as for other build objects)
● Server (core server builds)
● Appserver (application server builds)
● Webclient (web interface assemblies)
● Tests (running a full functional test, etc.)
')

Step 1: Commit to version control system.

It's all pretty trivial. With the help of hooks from the version control server, a GET request is sent to the CI server, the result of which will be the launch of a parameterized assembly (what it is and what it will be described below).
Example post-commit hook:

while read orev nrev ref do case "$ref" in refs/heads/i*) issue_branch="${ref##refs/heads/}" curl -X GET "http://_ci_/…./buildWithParameters?ISSUE_BRANCH=$issue_branch" ;; esac done 

Step 2: Run the parameterized build.

As the name implies, is an assembly that can have various parameters. In our case, there is usually a couple-three, for example, the name of the branch and the name of the product. Such an approach allows not to produce tasks that differ from each other in non-critical moments.

At this stage, the primary build takes place, for example, for a java project it will work with the gradle in the most primitive version, which looks like a “gradle clean build”.

This will allow you to identify random shortcomings in the code of a multi-module project and drive unit tests away.

Step 3: Run smoke testing.

This step is performed as part of the parameterized assembly. Smoke tests are performed within the slave of the machine on which the build task is started. This approach allows building and initial testing of various software (for example, an application server and a web client) in parallel, which reduces the waiting time for a new version by the testing department. At the same time, developers receive information about the problems they encountered earlier.

It is quite obvious that within the framework of these tests it is verified that after assembling the code (new or revised) the installed application starts and performs the main functions. In our company, depending on the project, they are written in different frameworks (for example, cucumber).

Here we will need the build parameters that we passed, because For different products, as in the case of acceptance testing, smoke testing scripts can vary greatly.

Step 4: Run acceptance testing.

At this stage, product acceptance testing is performed with different scenarios. I do not see any reason to paint it, because On this subject there are articles on Habré and the corresponding resources.

Step 5: Build a deb package.

Since our system is designed for a Debian distribution, the most obvious and convenient tool will be its native binary distribution package deb. About the structure of the package on Habré there are articles that can be found. I will tell you about some tricks that are used here.

First of all, you need to get a project revision for versioning and the ability to update a package directly from the repository via apt-get update and apt-get install.

To do this, we use the standard feature of the git "git describe", if you wish, you can get the build number in accordance with the tag by adding the - tags option. Usually, under a new minor version, we get our own tag.

By parsing this in a regular expression, we get something like “1075-g7fb7c67”, which will be the number of our revision. Coupled with the name and version of the product, we get the full name of our package, in our case we get something like “rtls-webclient-mines-1.0-dev_1.0-dev.1075-g7fb7c67_all.deb”.

Actually, for the assembly itself, we use the bash script. The bottom line is that it creates a build directory and puts templates for creating a package there. Further, depending on the product name, it puts the necessary modules and processes the template of the config file in the DEBIAN folder, using the sed command, writes up-to-date information about the package, having the information obtained above (for example with a revision, it looks like this: “sed -e” s /% REVISION% / $ REV / "-i $ PACKAGE / DEBIAN / control").

After preparing the build directory with fakeroot, the deb package itself is created with the command “dpkg-deb - build $ TMP_DIR $ {NAME} _ $ {VERS}. $ {REV} _all.deb”, where TMP_DIR is the build directory, NAME is the name of the product . VERS - version, and REV - pulled out revision. Then, using wput, the received packet is put into the repository, and the packet for sending is sent to the testing department.

Step 6: Work with the bug tracker.

We use redmine as a tracker bug, and the corresponding script is written for it, which determines the presence of the ticket number in the commit, and if there is one, the service user commented on the packet name in which the bug fix was applied. This allows the testing department to check for fixes almost immediately.

Step 7 (optional):

Every night we run the tasks of a full-featured testing system and with the help of the appropriate checkbox in the settings of the assembly triggers, which give us an understanding of the overall status of the project.

Good Build Example



An example of a collapsed assembly due to a failed test. The development team was notified and the last committer fixed the problem: