What is continuous integration?

Internet software development and release, has formed a set of standard processes, the most important component is continuous integration (continuous integration, referred to as CI).

This article provides a brief introduction to the concepts and practices of continuous integration.

　　First, the concept

Continuous integration refers to the frequent (multiple-day) integration of code into the trunk.

It has two main benefits.

1, quickly found errors. With each update, it is integrated into the trunk, which makes it easy to find errors quickly and locate errors.

2. Prevent the branch from significantly deviating from the trunk. If it is not often integrated, the trunk is constantly updated, resulting in future integration difficulties become larger, or even difficult to integrate.

The goal of continuous integration is to allow the product to be quickly iterated while maintaining high quality. Its core measure is that the code must pass through automated testing before it is integrated into the trunk. As long as one test case fails, it cannot be integrated.

"Continuous integration does not eliminate bugs, but makes them very easy to spot and correct," Martin Fowler said. "

In connection with continuous integration, there are two concepts, namely continuous delivery and continuous deployment.

　　Second, continuous delivery

Continuous delivery (continuous delivery) refers to the frequent delivery of new versions of the software to quality teams or users for review. If the review passes, the code enters the production phase.

Continuous delivery can be seen as the next step in continuous integration. It emphasizes that the software can be delivered anywhere, no matter how it's updated.

　　Iii. Continuous Deployment

Continuous deployment (continuous deployment) is the next step in continuous delivery, meaning that code is automatically deployed to the production environment after review.

The goal of continuous deployment is that the code is deployable at all times and can enter the production phase.

The prerequisite for continuous deployment is the ability to automate the steps of testing, building, deployment, and so on. It differs from the continuous delivery, which can be consulted.

(Photo source)

　　Iv. process

According to the design of continuous integration, the whole process of code from submission to production has the following steps.

　　4.1 Submissions

The first step in the process is for developers to submit code to the code repository. All subsequent steps begin with a commit (commit) of the local code.

　　4.2 Test (First round)

The code warehouse configures a hook for the commit operation, and runs automated tests as long as the code is submitted or merged into the trunk.

There are several kinds of tests.

• Unit tests: Testing for functions or modules
• Integration testing: Testing for a function of a whole product, also known as functional testing
• End-to-end testing: Full-link testing from the user interface to the database

The first round must run at least unit tests.

　　4.3 Build

With the first round of testing, the code can be incorporated into the trunk, even if it can be delivered.

Once delivered, the build is built before the second Test. The so-called construction, refers to the conversion of the source code can be run real, such as installation dependencies, configuration of various resources (style sheets, JS scripts, pictures) and so on.

The common build tools are as follows.

• Jenkins
• Travis
• Codeship
• Strider

Jenkins and Strider are open source software, and Travis and codeship are free to use for open source projects. They will all be built and tested and executed in one run.

　　4.4 test (second round)

When the build is complete, a second round of testing is necessary. If all the test content is covered in the first round, the second round can be omitted, and of course, the build step is moved to the front of the first Test.

The second round is the full test, the unit test and the integration test will run, if conditional, also do end-to-end testing. All tests are automated, and a few test cases that cannot be automated will be run manually.

It is important to emphasize that each update point of the new version must be tested. If the test coverage is not high, serious problems are likely to occur after you enter the later deployment phase.

　　4.5 Deployment

With the second round of testing, the current code is a version that can be deployed directly (artifact). All files of this version are packaged ( tar filename.tar * ) archived and sent to the production server.

The production server will package the files, unpack them into a local directory, point the symbolic Link (symlink) of the running path to the directory, and then restart the app. The deployment tools in this area are ansible,chef,puppet and so on.

　　4.6 rollback

Once there is a problem with the current version, roll back to the build results of the previous version. The simplest way to do this is to modify the symbolic link to point to the previous version of the directory.

　　V. Reference links

• Gergely Nemeth, continuous Deployment of node. JS applications
• Codeship, Continuous Integration Essentials

What is continuous integration?