Why we urgently need continuous integration (continuous integration)

Synchronize the original text to https://waylau.com/why-we-need-continuous-integration/

Continuous integration (continuous integration), which is what we often call CI, is the foundation of modern software development technology. This paper discusses the problems existing in the process of software development, explains the concept of continuous integration and continuous integration Server, and finally explores why we need continuous integration to solve these problems.

Problems in the current software development process

Before continuous integration is applied, the traditional development pattern is this:

• First, the project is divided into modules, allocation module to the corresponding developers;
• Developers develop a module to do unit testing;
• After all the modules have been developed, all the code is integrated by the project manager;
• The integrated project is deployed by the project manager to the test server and tested by the tester.
• A bug in the test process will bring up the problem record in the bug list;
• The project manager assigns the Bug to the corresponding responsible person to modify;
• Once the modification is complete, the project manager integrates the project again and deploys it to the test server;
• Testers perform regression testing in the next integration test;
• Deploy to the production environment after adoption;
• If the test does not pass, repeat the deployment to the test server, integration test, "bug-fix bug----"

The following problems may occur in this process:

1. Bugs are always found at the end

With the development of software technology, software scale is also expanding, software requirements are more and more complex, software can not be easily divided into modules by the way to develop, often need to cooperate within the project, there is a certain dependency between the modules, then the early existence of the Bug will often be found in the last integration time.

2. The more difficult it is to solve the problem later in the project

Many developers need to spend a lot of time in the integration phase to find the root cause of the Bug, plus the complexity of the software, the root cause of the problem is difficult to locate. And we all know that the longer the interval, the higher the cost of the Bug fix, because even the developer himself forgot what the Ghost Code was written, and had to read the code from scratch and understand the code.

3. Software delivery time is not guaranteed

It's because we can't fix bugs in a timely fashion, or we can't fix bugs early on, so that the entire bug-fixing cycle is stretched. In any case, it is impossible to deliver the software that knows the bugs to the customer.

And there's a lot of work that hasn't been anticipated in the early days-developers have to spend a lot of time looking for bugs; The testers are constantly in need of regression testing; The project manager has to struggle with the integration of the Damned code and deploy the repetitive work--eventually leading to the entire project's cycle lengthening, The delivery time point is dragged backwards.

4. Procedures often require changes

In some projects, programs often require changes, especially those of agile development practitioners. Because the product manager in the process of communication with the customer, often the actual software is the best prototype, so the software will be used as a prototype as a tool to communicate with customers. Of course, the customer's best hope is that the customer's idea can be reflected in the prototype immediately, which will cause the program to be modified frequently. It also means that the integration test, "assigning bugs, modifying bugs, and integrating code--" To test servers, is invisible and exploding.

5. Invalid wait to become more

It is possible to develop modules that are integrated with others, and testers are waiting for developers to fix bugs; The product manager is waiting for the new version to be ready for presentation; The project manager waits for someone else to submit the code. In any case, waiting means inefficient.

6. User satisfaction is low

The users here are broadly defined, can refer to the final customer, can also be product managers, company leaders, testers, and possibly even developers themselves. If you think about it, the three-month-old project was stretched to nine months or even a year, users can be satisfied with it! Product managers, company leaders often need to take the project as a prototype of the demonstration, the results tell me in the moment before the presentation of a lot of bugs have not been resolved, the project can not start inaccessible, which is called human.

The concept of continuous integration and continuous integration of servers

Well, in the above-mentioned issues, we find that some of the work is unavoidable, such as testing, modifying the program, integrating the work, and deploying the work. But in fact, in the entire workflow, there is a space that can be optimized, for example, integration testing work can be done in advance? Can there be automated means to replace testing, integration, and deployment work? Around these, the software industry's gurus put forward "continuous integration" slogans.

1. What is continuous integration, continuous integration Server

In software engineering, continuous integration (CI) refers to the practice of merging all of the developer's working copies into the trunk several times a day. Grady Booch The concept of CI for the first time in the 1991 Booch method, although at the time he did not advocate multiple integrations per day. XP (Extreme programming, extreme Programming) employs the concept of CI and advocates more than one integration per day.

and the continuous integration server is able to use automated means to liberate people's hands, to achieve continuous project integration tools. The software with it is TeamCity, Jenkins, Go and so on.

2. What's a "continuous"?

There is no clear definition of how many times a day needs to be integrated. In general, according to the actual needs of their projects to set a certain frequency, less likely several times, more likely to reach dozens of times. You can set up to trigger the integration by changing the code, or set a fixed time period to integrate, or manually click on the integrated button to "one-click Integration."

3. Workflow for Continuous integration

• When you start to change the code, the developer gets a copy of the current code base from the codebase (such as SVN, Git, and so on).
• When other developers commit the changed code to the code base, the copy gradually stops reflecting the code in the code base. The longer the code branch remains checked out, the greater the risk of multiple integration conflicts and failures when the developer branch is re-integrated into the mainline.
• When developers submit code to the code base, they must first update their code to reflect the most recent changes in the code base.
• When a repository differs from a developer's copy, they must take the time to deal with the conflict first.

Benefits of continuous Integration 1. The liberation of repetitive labor

Automated deployment frees up repetitive work such as integration, testing, deployment, and machine integration can be significantly more frequent than manual.

2. Fix problems faster

Due to the continuous integration of earlier access to change, earlier access to the test, will be able to identify the problem earlier, the cost of solving the problem is significantly reduced.

3. Faster delivery of results

Early integration and early testing reduce the chance of defects remaining in the deployment chain. In some cases, finding an error earlier also reduces the amount of work required to resolve the error.

If an integration server discovers errors during the build of the code, it can send a message or SMS to the developer to fix it.

If the integration server finds a problem with the current version in the deployment process, the integration server rolls back to the previous version. This will always have a version available on the server.

4. Reduce manual errors

One of the biggest differences between people and machines is that in repetitive actions, people are prone to make mistakes, and the odds of a machine making a mistake are almost zero. So, when we build the integration server, the next thing will be entrusted to the integration server to do it.

5. Reduced wait Time

Continuous integration shortens the time it takes to develop, integrate, test, and deploy every step of the process, thus reducing the waiting time that can occur in the middle. Continuous integration means that development, integration, testing, and deployment are ongoing.

6. Higher product quality

The integration server often provides code review, quality detection, and other functions. The code is not standardized or there are errors in the place will be identified, you can set up mail, SMS and other alarm. Developers can also continue to improve their programming capabilities through Code review.

Best practices for continuous integration 1. Frequently checked out code

In order to make your local copy and the version in the code base the smallest difference, it is recommended to check out the code frequently. Sometimes code conflicts are unavoidable, but minimal differentiation is easiest to solve. Moreover, the sooner you find the problem, the lower the cost of the solution.

2. Frequent Code submission

This is similar to the principle of article 1th, where code is frequently submitted, allowing the other person's checkout copy to be minimally differentiated from the version in the codebase.

3. Reduce branching, return to trunk

Although the code management tools support branching concepts, you should minimize their use. Assuming that there are multiple branches in parallel, the changes should be integrated into the trunk early, rather than maintaining multiple versions of the software at the same time. Backbone as a working version of software development.

4. Build with Automation

You can use Maven, Ant, and more to automate builds that can help you automate testing during the build process. The premise is that you have written unit test cases, such as JUnit.

5. Submit self-Test

Before submitting the work, each programmer must integrate all the code locally, do a complete build and run, and pass all the unit tests. This reduces the risk that integration testing will fail to build on the integration server.

6. The current status is visible to everyone

The integration server discovers problems during the continuous integration process and should be able to send alarms to the relevant stakeholders. At the same time, the wall can also be prominent in the location of a large screen display, the Integration Server status in real-time display on the large screen, convenient to remind the team members "hurry back to solve the problem"!

Challenges of continuous Integration 1. The resistance of team members to ideology

• Unable to accept new things: In any case, to stabilize the mentality of people still more. There are always people who think that old technology represents stability, and that new things often bring problems.
• There's not much work to be done with manual integration: Not all people are involved in the whole process of continuous integration, so there is no way to recognize the problem.

To solve this problem, we can set up a certain degree of continuous integration technology training, to improve the propaganda.

2. Conflict of management level

• Training continuous integration need to invest money ah, no money.
• Continuous integration server to increase hardware and software costs Ah, no money.
• Developers have been so high wages, more work more overtime should ah.

For this, you can estimate both the cost of the developer and the cost of the continuous integration of inputs (hardware and software).

3. Complexity of the production environment

• For example, the deployment of the build environment is in the external network, not directly accessible from the Internet and so on.

At present, this is the most troublesome, still in the study. The tentative idea is to have a white list for the extranet to set up a separate channel for the continuous integration server. Just thinking, not verified.

Of course, given the realities of the current work, it is possible to deploy the software to the demo server of your company first, so that at least it solves the prototype problem that the customer and product manager communicate with. After all, the actual software used by customers can be moderately relaxed on the updated frequency.

Resources

• Grady Booch. object-oriented Design with Applications.benjamin cummings,1991,3 (5): 209
• Paul M. Duvall,steve matyas,andrew glover.continuous integration:improving Software quality and Reducing Risk.Upper SADDL E river:addison-wesley,2007
• Http://martinfowler.com/articles/continuousIntegration.html

Why we urgently need continuous integration (continuous integration)