上QQ阅读APP看书，第一时间看更新

Implementing CI

To set up CI, it is, therefore, necessary to have a Source Code Manager (SCM) that will allow the centralization of the code of all members. This code manager can be of any type: Git, SVN, or Team Foundation Source Control (TFVC). It's also important to have an automatic build manager (CI server) that supports continuous integration such as Jenkins, GitLab CI, TeamCity, Azure Pipelines, GitHub Actions, Travis CI, Circle CI, and so on.

In this book, we will use Git as an SCM, and we will look a little more deeply into its concrete uses.

Each team member will work on the application code daily, iteratively and incrementally (such as in agile and scrum methods). Each task or feature must be partitioned from other developments with the use of branches.

Regularly, even several times a day, members archive or commit their code and preferably with small commits (trunks) that can easily be fixed in the event of an error. This will, therefore, be integrated into the rest of the code of the application with all of the other commits of the other members.

This integration of all the commits is the starting point of the CI process.

This process, executed by the CI server, must be automated and triggered at each commit. The server will retrieve the code and then do the following:

Build the application package—compilation, file transformation, and so on.
Perform unit tests (with code coverage).

It is also possible to enrich the process with static code and vulnerability analysis, which we will look at in Chapter 10, Static Code Analysis with SonarQube, which is dedicated to testing.

This CI process must be optimized as soon as possible so that it can run fast and developers can have quick feedback on the integration of their code. For example, code that is archived and does not compile or whose test execution fails can impact and block the entire team.

Sometimes, bad practices can result in the failure of tests in the CI, deactivating the test execution, taking as arguments: it is not serious, it is necessary to deliver quickly, or the code that compiles it is essential.

On the contrary, this practice can have serious consequences when the errors detected by the tests are revealed in production. The time saved during CI will be lost on fixing errors with hotfixes and redeploying them quickly with stress. This is the opposite of DevOps culture with poor application quality for end users and no real feedback, and, instead of developing new features, we spend time correcting errors.

With an optimized and complete CI process, the developer can quickly fix their problem and improve their code or discuss it with the rest of the team and commit their code for a new integration:

This diagram shows the cyclical steps of continuous integration that include the code being pushed into the SCM by the team members and the execution of the build and test by the CI server. And the purpose of this fast process is to provide rapid feedback to members.

We have just seen what continuous integration is, so now let's look at continuous delivery practices.