April 18, 2014 at 13:42Continuous Integration. The way to ensure reliability and trust in the system
Not so long ago, I became interested in the work of programming ideologues such as Kent Back, 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 I’ve been interested in lately in the software development process.
I want to share with the habrosociety what I learned from books and what I have to deal with in reality.
Continuous Integration (hereinafter CI) is a software development practice in which team members integrate at least once a day. Integration results are checked automatically using self-tests 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, also, CI eliminates the routine product assembly operations, improves the quality of the product, includes the profit from writing tests, which I think for all habroyuzer obvious.
In fact, CI allows you to get rid of assumptions during 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. Get rid of questions such as: “is the last assembly stable, what features are ready, does the code comply with company standards”, etc.
I ask everyone who is interested in the CI topic under cat.
Ideologically, CI is based on the following conventions:
A build 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:
Everyone who intends to implement CI will have to come to terms with the fact that automated tests are an integral part of the continuous integration process. And just static code analysis in automatic mode is not Continuous Integration, this approach is called Continuous Compilation.
CI uses tests at all levels except for research. Since on different resources the list of testing levels is different, I will give those described by the ideologists of CI:
A number of agreements have also been adopted on writing and running tests:
Each component of the system is responsible for the reliability of the system, so 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 answer your queries 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 system reliability is the product of the reliability of each component, totaling 73%. Now remember how many components 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 code repository complies with the standards, the level of code coverage and other metrics against the specified threshold.
One of the most important actions in the CI is the feedback mechanism, which, according to the provisions of the CI, should be implemented taking into account the rule: “To the right people. At the right time. In the right way. ” (orig. - “The right people. The right time. The right way.”).
The following popular feedback mechanisms are:
Also, it is worth noting that many IDEs (NetBeans, PHPStorm) allow you to synchronize with popular (Jenkins, TeamCity) CI servers.
It just so happened that while participating in the development of a “bloody enterprise project”, I had to adapt the ideal CI version to the realities of the harsh world. By the time I started CI, the company already had at its disposal:
The main problems are:
Solutions:
Plans:
CI practice, which is currently gaining popularity in connection with the development of an increasing number of "adult" solutions that bear serious responsibility for the quality of their product.
For those interested, I suggest reading books on CI and related or derivative topics:
Paul Duvall - 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 I’ve been interested in lately in the software development process.
I want to share with the habrosociety what I learned from books and what I have to deal with in reality.
Theory
Continuous Integration (hereinafter CI) is a software development practice in which team members integrate at least once a day. Integration results are checked automatically using self-tests 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, also, CI eliminates the routine product assembly operations, improves the quality of the product, includes the profit from writing tests, which I think for all habroyuzer obvious.
In fact, CI allows you to get rid of assumptions during 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. Get rid of questions such as: “is the last assembly stable, what features are ready, does the code comply with company standards”, etc.
I ask everyone who is interested in the CI topic under cat.
Ideologically, CI is based on the following conventions:
- often (at least 1 time per day) "upload" your code to the repository
- write automated tests
- run private builds (a build process that runs using the source code currently located in the local developer repository)
- do not "fill" idle code
- repair broken build immediately
- ensure that all tests and checks pass
- do not pump broken code from the repository
Build script
A build 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:
- Clearing previous run results
- Compilation (or static code analysis for interpreted languages)
- Database Integration
- Run Automated Tests
- Running other checks (code compliance with standards, checking cyclomatic complexity, etc.)
- Software deployment
Automated Tests
Everyone who intends to implement CI will have to come to terms with the fact that automated tests are an integral part of the continuous integration process. And just static code analysis in automatic mode is not Continuous Integration, this approach is called Continuous Compilation.
CI uses tests at all levels except for research. Since on different resources the list of testing levels is different, I will give those described by the ideologists of CI:
- unit tests
- component tests
- functional tests
- system tests
A number of agreements have also been adopted on writing and running tests:
- faster tests should be run first
- tests should be categorized
- tests should be written for all bugs
- test cases should be limited to one test
- tests should run without error when restarting
How reliable is the system
Each component of the system is responsible for the reliability of the system, so 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 answer your queries 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 system reliability is the product of the reliability of each component, totaling 73%. Now remember how many components 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 code repository complies with the standards, the level of code coverage and other metrics against the specified threshold.
Continuous feedback
One of the most important actions in the CI is the feedback mechanism, which, according to the provisions of the CI, should be implemented taking into account the rule: “To the right people. At the right time. In the right way. ” (orig. - “The right people. The right time. The right way.”).
The following popular feedback mechanisms are:
- SMS
- browser plug-in
- traffic light assemblies
- sound alert
Also, it is worth noting that many IDEs (NetBeans, PHPStorm) allow you to synchronize with popular (Jenkins, TeamCity) CI servers.
Reality
It just so happened that while participating in the development of a “bloody enterprise project”, I had to adapt the ideal CI version to the realities of the harsh world. By the time I started CI, the company already had at its disposal:
- CI server (Jenkins) with a couple of dozen builds
- unit tests, albeit a small amount
- build scripts, mainly on the shell, but with a tendency to switch to apache ant
- standard feedback mechanism - email
The main problems are:
- developers don't even want to write unit tests
- feedback is slow, many letters are simply ignored
- bugs are not covered by unit tests
Solutions:
- reports on CI and unit testing
- educational work with each developer
- cooperation with QA department
- change in the development process, involving the mandatory writing of tests
Plans:
- improve the feedback mechanism, perhaps leave the same, having previously compiled for developers an algorithm for finding the reasons for the failed assembly
- to establish the process of writing unit tests before the code, in fact, the transition to TDD
- cooperation with the QA department in order to detect bugs even at the stage of compiling documentation, as well as for compiling and writing test scripts
Epilogue
CI practice, which is currently gaining popularity in connection with the development of an increasing number of "adult" solutions that bear serious responsibility for the quality of their product.
For those interested, I suggest reading books on CI and related or derivative topics:
Paul Duvall - Continuous-Integration
Jez Humble - Continuous Delivery
Robert Martin - Clean Code, Clean Coder