Continuous integration. The way to ensure reliability and trust in the system
Not so long ago, I became interested in the writings of programming ideologists such as Kent Beck, Robert Martin, Martin Fowler, Paul Duval.
Their books impressed me and inspired me to try some of the practices described. Refactoring, TDD, XP, and finally Continuous Integration, is what interests me recently in the software development process.
I want to share with the habocoobschestvomu what I learned from the books and what you have to face in reality.
')
Continuous Integration (hereinafter referred to as CI) is a software development practice in which team members perform integration at least once a day. The integration results are checked automatically using autotests and static code analysis.
Using CI allows you to track integration errors in time, make the system and development process more “transparent” for all team members, and CI eliminates the routine operations of product assembly, improves product quality, and includes the profit from writing tests, which I think for all habrouyuzerov obvious.
In fact, CI allows you to get rid of assumptions in the software development process. The manager assumes that the product is ready and stable, the programmer - that there are no errors in the code, etc. To get rid of questions such as "whether the latest build is stable, what features are ready, whether the code complies with company standards", etc.
Anyone who is interested in the topic of CI please under the cat.
Ideologically, CI is based on the following agreements:
An assembly script is a set of commands that will be executed when the integration process starts. Most often it looks like the following set of steps:
Anyone who intends to implement CI will have to accept the fact that automated tests are an integral part of the continuous integration process. And only static code analysis in automatic mode is not Continuous Integration, this approach is called Continuous Compilation.
CI uses tests of all levels except research. Since on different resources a list of testing levels is different, I’ll give those described by the CI ideologues:
There are also a number of agreements on writing and running tests:
Every component of the system is responsible for the reliability of the system; therefore, it is very important to pay attention to improving the reliability of the system. I think that no one would like to use a computer that does not respond to your requests 20% of the time. In order to demonstrate the importance of reliability, imagine that you have a system of 3 components. Each of these components is 90% reliable, so the overall reliability of the system represents the product of the reliability of each component, totaling 73%. Now remember how many components are in the last application you wrote ...
Continuous Inspection is one of the steps of the build script, which involves checking that the code in the repository matches the code, matches the code coverage level, and other metrics to the specified threshold.
One of the most important actions in CI is the feedback mechanism, which, according to the provisions of the CI, should be subject to the rule: “Right people. At the right time. The right way. "(Orig. -" The right people. The right time. The right way. ").
The following popular feedback mechanisms exist:
It is also worth noting that many IDEs (NetBeans, PHPStorm) allow you to synchronize with popular (Jenkins, TeamCity) CI servers.
It just so happened that I took part in the development of a “bloody enterprise project”; I had to adapt the ideal version of CI to the realities of a harsh world. By the time I started CI, the company already had:
Main problems:
Solutions:
Plans:
CI is a practice that is currently gaining popularity due to the development of an increasing number of “adult” solutions that are seriously responsible for the quality of the product they produce.
For those interested, I suggest reading books on CI and related topics or those derived from it:
Paul Duval - Continuous-Integration
Jez Humble - Continuous Delivery
Robert Martin - Clean Code, Clean Coder
Their books impressed me and inspired me to try some of the practices described. Refactoring, TDD, XP, and finally Continuous Integration, is what interests me recently in the software development process.
I want to share with the habocoobschestvomu what I learned from the books and what you have to face in reality.
')
Theory
Continuous Integration (hereinafter referred to as CI) is a software development practice in which team members perform integration at least once a day. The integration results are checked automatically using autotests and static code analysis.
Using CI allows you to track integration errors in time, make the system and development process more “transparent” for all team members, and CI eliminates the routine operations of product assembly, improves product quality, and includes the profit from writing tests, which I think for all habrouyuzerov obvious.
In fact, CI allows you to get rid of assumptions in the software development process. The manager assumes that the product is ready and stable, the programmer - that there are no errors in the code, etc. To get rid of questions such as "whether the latest build is stable, what features are ready, whether the code complies with company standards", etc.
Anyone who is interested in the topic of CI please under the cat.
Ideologically, CI is based on the following agreements:
- often (at least 1 time a day) “upload” your code to the repository
- write automatic tests
- run private builds (build process that is performed using the source code currently located in the local developer repository)
- do not "fill" inoperative code
- fix broken build immediately
- ensure that all tests and checks pass
- do not download broken code from repository
Build script
An assembly script is a set of commands that will be executed when the integration process starts. Most often it looks like the following set of steps:
- Cleaning up previous run results
- Compilation (or static code analysis for interpreted languages)
- Database Integration
- Running Auto Tests
- Running other checks (code compliance with standards, checking cyclomatic complexity, etc.)
- Software deployment
Automatic tests
Anyone who intends to implement CI will have to accept the fact that automated tests are an integral part of the continuous integration process. And only static code analysis in automatic mode is not Continuous Integration, this approach is called Continuous Compilation.
CI uses tests of all levels except research. Since on different resources a list of testing levels is different, I’ll give those described by the CI ideologues:
- unit tests
- component tests
- functional tests
- system tests
There are also a number of agreements on writing and running tests:
- faster tests should be run first
- tests should be categorized
- all bugs should be written tests
- test cases should be limited to one test
- tests should run without error when rerun
How reliable is the system?
Every component of the system is responsible for the reliability of the system; therefore, it is very important to pay attention to improving the reliability of the system. I think that no one would like to use a computer that does not respond to your requests 20% of the time. In order to demonstrate the importance of reliability, imagine that you have a system of 3 components. Each of these components is 90% reliable, so the overall reliability of the system represents the product of the reliability of each component, totaling 73%. Now remember how many components are in the last application you wrote ...
Continuous inspection
Continuous Inspection is one of the steps of the build script, which involves checking that the code in the repository matches the code, matches the code coverage level, and other metrics to the specified threshold.
Continuous feedback
One of the most important actions in CI is the feedback mechanism, which, according to the provisions of the CI, should be subject to the rule: “Right people. At the right time. The right way. "(Orig. -" The right people. The right time. The right way. ").
The following popular feedback mechanisms exist:
- SMS
- browser plug-in
- traffic light assemblies
- sound alert
It is also worth noting that many IDEs (NetBeans, PHPStorm) allow you to synchronize with popular (Jenkins, TeamCity) CI servers.
Reality
It just so happened that I took part in the development of a “bloody enterprise project”; I had to adapt the ideal version of CI to the realities of a harsh world. By the time I started CI, the company already had:
- CI server (Jenkins) with a couple dozen builds
- modular tests, although a small amount
- build scripts, mostly on the shell, but with the tendency to move to apache ant
- standard feedback mechanism - email
Main problems:
- developers don't even want to write unit tests
- reaction to the feedback mechanism, slow, many letters are simply ignored
- bugs are not covered by unit tests
Solutions:
- CI and unit testing reports
- educational work with each developer
- cooperation with QA department
- a change in the design process that requires writing tests
Plans:
- to improve the feedback mechanism, perhaps, to leave the same, having previously developed an algorithm for developers to search for the causes of the fallen assembly
- adjust the process of writing unit tests before the code, actually switching to TDD
- cooperation with the QA department in order to detect bugs at the stage of writing documentation, as well as for writing and writing test scripts
Epilogue
CI is a practice that is currently gaining popularity due to the development of an increasing number of “adult” solutions that are seriously responsible for the quality of the product they produce.
For those interested, I suggest reading books on CI and related topics or those derived from it:
Paul Duval - Continuous-Integration
Jez Humble - Continuous Delivery
Robert Martin - Clean Code, Clean Coder
Source: https://habr.com/ru/post/219891/
All Articles