1. What is continuous integration )?
This term has been in the software development field for N years. A simple definition is as follows:
CI is a practice that enables the team to receive feedback and make improvements on a continuous basis without waiting for the development cycle to come up with a solution for defects. To put it simply, all code in repository is automatically checked out to an empty directory for every code Submission by a developer, and all test cases are automatically run. If the submission succeeds, accept the submission. Otherwise, it is a failed revision. For more details, refer to Martin Fowler's continuous integration.
Ii. value and cost of continuous integration
In a fashionable word, it is called "existence is reasonable ". Since continuous integration has been around for so long and there are no signs of disappearance, it is valuable. So what is its value? Some people summarize the following: (1) reduce risks; (2) reduce manual processes; (3) generate building results; (4) sense of security.
The cost of continuous integration lies in the maintenance cost of continuous integration code and the time cost of integration. As the project progresses, the hardware and software environments become more complex and the finished Code expands. At this point, the team needs to modify or add the original test code to adapt to these changes. At the same time, the time required for each integration also gets longer, which is the cost of continuous integration. A blog says, "This kind of integration is so frequent, and the number of times the code commit has been continuously integrated. The premise is that the cost of integration is very low, or it is completely automated ."
3. What should continuous integration be automated?
We need to get as much value as possible at the lowest possible cost. Which automation is necessary. Jez humble mentioned that automation should be achieved at least six points, namely (1) Automated run testing; (2) Automatic Production of deployable binary products; (3) automatically deploy finished products to an approximate production environment; (4) automatically tag codebase; (5) automatically run regression testing; (6) automatically generate a measurement report.
Iv. Selection of continuous integration servers
You should select and configure the continuous Integration Server correctly before performing continuous integration practices. Mature CI servers include: cruisecontrol, anthill, bamboo, teamcity, and continuum. As an open-source product, cruisecontrol is accepted by many development teams for its extensive support for various SCM and build tools. Development automation expert Duvall uses consistent evaluation criteria and many descriptive examples to introduce some open source CI servers, including continuum, cruisecontrol and luntbuild. It also pointed out that "tools should be analyzed according to their specific technical and policy needs ". Use the following five metrics to evaluate CI tools: (1) features; (2) reliability; (3) life cycle; (4) target environment; (5) ease of use. The results are as follows:
Cruisecontrol is the only continuous integration tool that I have actually used. It is now flexible and powerful, and it is much easier to configure and manage than it was two years ago. Why is it powerful? As long as you want to solve the problem, it will also consider it. Some cruisecontrol best practices on a friend's blog prove this, as long as you are willing to practice it.
5. Only continuous integration servers are far from enough.
As Jez humble said, The cruisecontrol and other Ci tools are essentially just a timer, time-to-date, to do what you want it to do. Therefore, it is necessary to combine other tools to demonstrate the true nature of continuous integration. What are these tools? To test the code, you must use some testing tools, such as JUnit, jwebunit, and Selenium. To check the code standards, you must use code standard check tools such as checkstyle; to understand the test coverage rate, you may need to use jcoverage. Of course, tools like ant and make are needed to get binary files.
VI. The most important thing: Practice and Reflection
You may know these things, and some people may have already practiced them. No matter what the results of these practices are, do not forget to sum up and reflect on them. If these practices are successful, don't owe them to this tool. Instead, you should summarize why they are successful. If you want to, you can share them with us. If these practices fail, don't owe them to this tool. Instead, you need to reflect on whether the tool is correctly used and whether team members like it. Why?