The play of continuous integration says Check-in Dance

Add by Zhj: Let's talk about the definition of continuous integration, as ThoughtWorks chief scientist Martin Fowler in the second edition of Continuous integration, "continuous integration is a software development practice." In continuous integration, team members frequently integrate their work results, usually at least once per person per day, or multiple times. Each integration is automatically built (including automated testing) validation to quickly identify integration errors. Many teams have found that this approach can significantly reduce the problems caused by integration and speed up team collaboration software development. ”

Here is a brief introduction to the second edition of "Continuous Integration": Http://www.infoq.com/cn/articles/ci-theory-practice

Original: Http://www.infoq.com/cn/news/2011/01/ci-check-in-dance

It is well known that there are many best practices in agile software development methodologies, both managerial and technical. Not every team can use all of the best practices at the beginning of the agile effort, and not every practice can take effect in a short period of time. But one of the best practices is the team's mandatory choice, which is continuous integration, but that doesn't mean that continuous integration is easy.

Although ThoughtWorks's chief scientist Martion folwer the definition of "continuous integration", everyone has a different understanding of it due to their own background and experience. In a narrow sense, continuous integration can be thought of as a recurring build-up of a software system based on some or some change (note: The build activity here refers not only to the compilation package, but also to various automated testing, deployment, and release activities). However, it ignores the point that any practice should include the "interaction with people" factor. Therefore, in broad sense, continuous integration should be the software development team under the constraints of the above activities to adopt the entire development process and activities. It emphasizes the interaction between the development team and the continuous Integration System. We've seen teams that have been very successful in continuous integration, and have seen poorly performing, continuous integration, and even failure cases.

So, how do you get the most out of continuous integration? This is done from the many aspects involved in continuous integration, and according to the specific circumstances of the team (such as the size of the team, the composition of personnel and whether it is distributed team) and the characteristics of the developed software itself (enterprise application software, or middleware?). is embedded software, or Internet products, etc.) to develop practical strategies and implementation steps. This column will explore methodologies, tools, and experiences related to continuous integration, continuous deployment and continuous delivery. The author of the ThoughtWorks company has been involved in a continuous integration and release management product go delivery and external consulting services for the column provides a lot of material, but also thanks Xiaopeng, Li Yanhui, Hu, Jian Li and other support and help for the column content.

In software development, the problems that continuous integration practices can solve are early integration and early feedback. Therefore, although all version control tools currently in vogue offer branch/merge functionality, it is recommended to use Single branch development strategy for continuous integration in teams of fewer than 20 people. This reduces the overhead of multi-branch opening as at merge time. Also, because ideally, each branch requires a dedicated, continuous integration environment (including a continuous integration server, build environment, and test environment), single branch reduces the need for a continuous integration environment (which is especially important when the compilation time is longer or when the test case is large).

Once the team has completed the initial build of a continuous integration server, writing a one-click Compilation and test script work, it is necessary to consider how to use the continuous integration environment to effectively develop team collaboration. Someone must have asked:

"It's not a waste of time for everyone to merge code when they commit," he says. ”

This problem is also the problem that continuous integration is expected to solve. Whenever a developer submits code, it is an integration with other developers ' work results. If everyone is able to submit code frequently, then the frequency of code integration will increase, and with the strong support of continuous integration, the potential problems in the code will be exposed earlier (such as code compile link problems, automated test failures reflect the problem of code functionality, or the need to understand inconsistencies, etc.), So that the team can resolve it early.

Of course, the frequent submissions encouraged by continuous integration do not refer to the type of version control library as a backup tool, unconstrained "random" commits, but also team development process constraints. Let's explore the "What is the team development process in a continuous integration environment".

Let's first imagine a software development scenario.

First, use the version management tool to do the backup

The hero of the story is Joe, who is going to write a game, so he built a version control library with subversion to save the code and then write the code. Joe's development process is like this.

1. Check out a code from the code base;
2. Modify some code to add a function;
3. Run an automated test locally;
4. After the test passes, submit the code to the version control repository;
5. Repeat the previous steps.

As shown in 1.

Second, build continuous integration Server to do automatic construction

"It's too much trouble to run automated tests locally and manually," Joe thought, "Why don't you let the machine do this repetitive work?"

So, Joe searched the Internet and found that the continuous integration tool was doing this, and then found an old machine and built a continuous integration server with CruiseControl. His development process has also changed to:

1. Check out a code from the code base;
2. Develop new features or modify bugs;
3. Submit to the version Control Library and think about the next feature implementation;
4. Continuous integration Server run Automation build and test;
5. If the test passes, go to step (1);
6. If the test does not pass, go to step (2). As shown in 2.

Three, multi-person parallel development

Two weeks later, the game was a prototype, and Joe introduced his game creation to several of his friends, who were very fond of it and therefore joined the game development. The trouble soon arose. Build results often fail in the continuous integration server, so problem cleanup is done every time the code is checked out. So the job sits down with friends to discuss how to solve the problem.

Alice said: "Each of US pulls an independent branch, and when everyone's functional development is completed, then merge together is not OK?" ”

Joe doesn't agree with this approach. "The needs of the game are not clear, we should often close together to see the effect." So let's develop it on the same branch. Let's talk about how to make this kind of failure less. ”

So they spent some time discovering that there were two major causes of failure.

1. There is a problem with the local code, the original will not compile or will cause the test failed, but still submitted;
2. When you start a new feature, you don't pay particular attention to the continuous integration state on the branch, directly merging the code on the main branch directly with the local code;

Joe suggests that the development process should turn out to be 3:

1. Everyone can only check out the code from the latest version of the continuous integration that was successful before developing the new Code;
2. Develop new features or modify bugs;
3. The code on the main branch is again taken to a local merge before committing;
4. Run local tests to ensure that tests can be passed;
5. Submit the code to the main branch and run the test again by the continuous integration Server.
6. If the test passes, go to step (1);
7. If the test does not pass, go to step (2) until the build on the continuous integration is repaired.

However, Alice raised objections. "Now that you've run the tests locally, why do you want to run it again on the continuous integration server?" she said. ”

Joe explains: "The main reason is that each of us is not exactly the same local environment, it is possible that the ' it is not a problem in my machine ' phenomenon, so still need to run on a separate continuous integration server again." ”

So that's what we decided.

Four, two times the purpose of local construction

Four weeks later, Joe took a long time to complete a new feature and was ready to submit it. He then merges the current code of the branch with its native code. The local test was then run, but the test failed. It took him a long time to locate the problem in his own modified function, or in the code that was being combined. This allowed him to reflect on the submission process.

"If I had to run a local test before I could get into someone else's code, it would be nice to verify that my code was fine, but the local test didn't take much longer." ”

So he told the other people the idea, and most people agreed to do it. Thus, the submission process becomes this:?

1. Everyone can only check out the code from the latest version of the full success of continuous integration before developing new Code;
2. Develop new features or modify bugs;
3. Run local tests and fix them immediately if there is a failure until the cost of testing;
4. The code on the main branch is again taken to a local merge before committing;
5. Run local tests to ensure that tests can be passed;
6. Submit the code to the main branch and run the test again by the continuous integration Server.
7. If the test passes, go to step (1);
8. If the test does not pass, go to step (2).

This process is called "check-in Dance".

Alice added: "When we check out the code from the main branch, it must be the latest version that is verified by continuous integration." This avoids checking out the code that is problematic and affects your local code. "The entire procedure is shown in 4.

Five, continuous integration of tokens

After a few days, someone called everyone together, this time Alice. She said:

"I'm having a problem today. After I submit the code, waiting for the continuous integration server to return the results, Bob commits the code. Fortunately, the code I submitted passed the test, otherwise I would have to fix it on Bob's code. Therefore, I suggest that we need to set up a token for submission, which can only be submitted by the person who has received the token. That is, when a person finishes a local test, go get the token. Once you've got it, code merging, local testing, and submission. The token can only be returned when the continuous integration server returns a successful result when it is submitted. So that's not going to happen to me and Bob. ”

But Bob does not agree, "there is nothing wrong this time, why do you do it?" ”

At this point, Joe picked up the words and said, "Alice's advice is very good, I've had one of those things, and after that Test failed, it took me a long time to find out that the problem wasn't in my submission, but in Mary's submission." After I repaired it, I made another commit. "Since most people agree to do so, the team decided to give it a try. Because the test run time is very short, there is no bottleneck in the commit and integration work. The submission process is shown in 5.

It seems that things are over here. However, the game was taken by an investment company, decided to make a bigger investment, recruit more developers, let it become an open game platform. So what are some of the problems that Joe and his friends are going to face next?

Thank Propellerhead for the planning and revision of this article.

Continuous integration of the play said Check-in Dance (turn)