What Is Continuous Integration?

Continuous integration is a software development practice, where team development members often integrate their work, and usually each member integrates at least once a day, which means that integration may occur multiple times per day. Each integration is verified through automated builds (including compilation, release, and automated testing) to detect integration errors early.

Master Martin Fowler defines continuous integration like this: Continuous integration is a

reduce risk

Multiple integrations and tests are performed throughout the day, which helps to check for defects, understand the health of the software, and reduce assumptions.

Reduce repetitive processes

Reducing repetitive processes can save time, money, and effort. It's easy to say and hard to do. These time-consuming repetitive tasks can occur at any point in our project activities, including code compilation, database integration, testing, review, deployment, and feedback. Through automated continuous integration, these repetitive actions can be turned into automated, without much manual intervention, allowing people to invest more time in brainstorming and higher value things.

Generate deployable software anytime, anywhere

Continuous integration lets you release software that can be deployed at any time. From the outside, this is the most obvious benefit of continuous integration. We can talk about improving software quality and reducing risks, but for customers, deployable software products are the most practical assets. With continuous integration, you can often

1. Unified code base

2. Build automatically

3. Automatic test

4. Everyone submits code to the codebase stem every day

5. After every code submission, a build is triggered on the continuous integration server

6. Ensure fast builds

7. Automatic test to simulate production environment

8. Everyone can easily get the latest executable applications

9. Everyone knows what is going on

10.Automated deployment ^[1]

1. All developers need to

When making changes, developers will copy from the current base code base for operations, and other developers will submit code changes to the source code base and replace the source code base code by means of a copy. Not only change the current code base, but new code can also be added as a program base, other shared resources and potential conflicts.

The longer the branch code remains in the fetched state, the more likely it is to encounter the risk of multiple integration conflicts and failures when the branch code developers perform mainline reintegration. When developers submit code to the code base, they must first update the code to reflect their changes in the code base because they get a copy. The more changes the code base contains, the more work developers must run before committing their own changes.

Finally, the library may become very different from the developer's target code. They enter a stage sometimes called merger hell or integration hell. At this time, the integration time spent by the developer will exceed the initial code development time.

Continuous integration involves pre-integration and pre- and regular integration, so as to avoid stepping into the trap of integration hell. The goal of practice is to reduce rework, cost and time.

The practice of continuous integration supplement is that before the results are submitted, each developer must run a complete build and run and pass all unit tests and integration tests. These are when the continuous integration server detects a new commit of the code It must be done regularly and automatically. ^[2]