Continuous Integration: Software Quality Improvement and Risk Reduction

Roughly flipping through the jolt award book "Continuous Integration: Software Quality Improvement and Risk Reduction", I found that the basic principles are no different from what I was doing before, but the other party is obviously not satisfied with all the trials and experiences, and I am in the process of specific operation. However, I stopped countless times. According to Mr. Yang Ming’s words, knowledge that cannot be practiced is really not true knowledge. Combined with my own understanding, I put a small summary after reading to the back and use it to gradually improve my work. .

      The first point of realizing continuous integration, in short, is the need to achieve "one-click construction", which means "under any circumstances, you can obtain an unambiguous share from the specified service according to your needs. materials to successfully complete this build process.” This is a bit abstract, but it is clear when it is divided into several layers. To obtain unambiguous construction materials, including code, configuration, etc., then the intervention of version management tools is definitely required, such as centralized SVN, which manages code, and git, which manages code in a distributed manner, are the leaders in this type of tool; after obtaining reliable materials, the construction also needs to isolate the damage caused by the environment or configuration changes, such as running the build on the developer's own machine, If it cannot run on the server, then it is not a good build. At this time, some configuration items need to be used to adjust the difference between the platform or other build environments; the third point derived from this is that the build cannot depend on a specific IDE. , because it's not something that all environments should have, which I'm particularly aware of.
       The second point of continuous integration is that on the basis of the first point above, it is necessary to add a series of tools or processes that can measure product quality in the construction process. It's easy to understand that continuous integration is not about compiling code continuously, or more than that. It's more about monitoring whether the change process introduces complexity, duplication, bad code style, and hidden bugs. These are the key indicators of the health of a product, just like a person's height, weight and blood pressure. Only with these processes can the construction form an objective report on the product. The tools I have used in this regard include sonar, pmd, checkstyle, findbug, etc. Of course, there is a tool that is not an off-the-shelf tool, but one thing that needs to be accumulated by developers, that is, the automated test code for the product. According to my practice, in an existing code that has no tests at all Adding tests to the project carries a heavy historical burden. The data in the report with extremely low code test coverage will become the reason for developers to give up unit testing in the end. This can probably be explained by the "broken window theory". , once the developer feels hopeless to deal with the legacy code, he may turn to conform to history and give up writing tests, which will lead to the hole getting bigger and bigger. I think it is more reliable for developers to insist on adding tests to new functions, and then add tests to old code that has problems, and carry out step by step.
       Then there's the third aspect of continuous integration, which naturally follows from the second, since we see integration builds as a "useful" thing, not a toy or a fad, then the second The metric reports that are added in the next step must be taken seriously, and these data must be notified to the corresponding personnel in a timely manner and processed in a timely manner. Some simple principles include: failed builds must be fixed as soon as possible; developers strive to establish their own private build process, avoid committing things that cannot be built to the repository, etc. Notifying and presenting this current continuous integration tool is doing a good job. The hudson and its various plug-ins I have used can meet the application of most occasions, but the most important thing is the human link. Someone must continue to follow up the reports generated by continuous integration, and timely throw out some that need the attention of the team In this way, a series of development risks can be avoided and the quality and efficiency of development can be improved.