Why do you want to do continuous integration

continuous integration can be used in most companies today or in the same way. Some will choose some open source tools, such as Cruisecontrol,hudson,luntbuild and so on, some will buy a better service, stronger features of the commercial products, such as teamcity,quickbuild and so on, And some will choose their own implementation, such as Cron+ant/maven/make and so on. So what's the effect of using it? Is it really going to work out the expected effect? I am afraid not, otherwise there will not be so much discussion. [@[email protected]]

continuous integration and agile programming

In the agile world, test-driven and continuous integration are known as the two cornerstones of agile programming, so many people's concept of continuous integration is to achieve agile programming. It's a mistake to know. In fact, as early as the concept of agile programming, continuous integration as a best practice has been adopted by many companies, but as a concept, is by Uncle Martin in order to promote agile and thus the promotion of the popular. Continuous integration is itself a practice, not limited by any development model, can be used in any kind of development model, or it can run very well.

continuous integration or stage integration

A lot of people say that I don't do continuous integration, so I work very well. Because we have a (small) stage out of a version, still control very well. I have to congratulate you, first of all, continuous integration or phase integration, you do, do it well, than not do much better, also make your project management on the track. The difference between the two is only the frequency.

So what is the ideal way to be more consistent with project development and management? In fact, this question was answered by Steve McConnell in his book, Code complete, which won the Jolt Award. "Phased integration may be the best approach for a mini-program," he said. What is a mini-program, he says, is the two or three-class program, and if you're lucky, stage integration can be the best way for you. Of course, this man is an old beauty, we all know foreigners, are more stupid, so, he said micro-program, for our 5,000-year civilization of the Chinese people said, you can expand it, for a small project, that is the kind of twenty or thirty class projects, perhaps the use of phase integration will not be a problem. However, if you're really lazy enough to do a phase integration, you can at least ask God to bless your project.

Why do you want to do continuous integration

Many people are certainly very fastidiously with my view, they think that even without doing continuous integration, even did not do the stage integration, but the project is completed on time, even ahead of schedule, and still complete the very ideal, boss satisfaction, customer satisfaction. and do continuous integration, nothing is to receive an e-mail, said the build succeeded, the build failed, but it is a continuous compilation, I make a command to compile, do not know? To do a daily build, I have to go to set up, but also to spend the strength to configure, the effect is not necessarily good to where to go.

For some of these questions, I think first of all we have to figure out exactly why we have to do continuous integration, and what benefits continuous integration can bring. Also mentioned in code complete, for continuous integration (in the book, the term Steve McConnell uses incremental integration) has the following advantages:

easy to locate errors. That is, when your continuous integration fails, it means that your new code or modified code causes errors, so you can easily know who made the mistake and who to talk to.
achieve system-level results early in the project. Since the code is already integrated, even though the entire system is not yet available, at least you and your team can already see it already there.
improve control of progress. This is obvious, if you are integrating every day, and of course you can see what features are available every day, and what features are not yet implemented. If you're a programmer, you don't have to worry about how much I'm doing when you report a task, and if you're the project manager, then you're not bothered by what the programmer says is the concept of 50% of the code being completed.
improve customer relationships. The reason is ditto.
test each unit in the system more fully. This is one of the great benefits of the combination of daily build and smoke test that we often talk about.
can build the entire system in less time. I'm afraid you'll have to come to a conclusion when you implement it. As far as we are concerned, continuous integration does not shorten the time for each project, but it is more controllable and more secure than when it is not implemented.

Over time, the more benefits of continuous integration are gradually recognized, such as:
facilitates the collection of project development data。 For example, changes in project code volume, often error tests, source code that often goes wrong, and so on.
Continuous code quality improvements in combination with other tools。 such as with Checkstyle, PMD, FindBugs, FxCop and so on the combination.
continuous testing in combination with test tools or frameworks。 such as with Xunit,silktest, LoadRunner and so on the combination.
Easy Code Review。 In each build, we can see what changes have been made to the previous build, and then we can implement code review for these changes.
Easy management of the development process。 For example, to submit a development build to the Test team for testing, the test is satisfied, and then submitted to the release group to publish.

How to do continuous integration

Continuous integration has many, many benefits. But continuous integration to do well, itself has a lot of attention. From the selection of continuous integration tools to the implementation of continuous integration, every point can affect your use of continuous integration. Continuous integration is not a continuous compilation, nor is it just a tool for sending e-mails.

工欲善其事, its prerequisite. It's important to choose a good tool first, and in my other post, "selection of continuous integration tools," I've already mentioned, and there's no more talking here. Use it, I think quickbuild really good.

The tool has been selected, how to do it specifically? There is no standard to follow, each project is not the same, I would like to talk about our specific process here.

First, we have some specifications for coding to follow, so we have developed a series of rules for FindBugs and PMD to check the code.
Second, we use Cobertura as our Code coverage tool.
Again, we use JUnit as our Unit test tool
Based on the points above, we have written our ant script, which has a series of tasks, basically:
Compile, source code Analytics, Unit test, generate reports, generate Javadoc, package artifacts

This is a complete process that is often used in the Java domain.

With such a script, we begin to configure our project to Quickbuild, in Quickbuild, we configure a configuration, and then set up our SCM repository, corresponding to our ant task, We configured a series of step to complete the process. Since our tests need to be cross-platform, corresponding to the task with the same unit test, we use Quickbuild's distributed step function, which can be tested on different platforms, which is also a benefit of using CI server.

Corresponding to this configuration, we have configured four sub-configurations, distributed development configuration, QA configuration,integration Configuration and Release configuration. These configurations correspond to the four phases of our development process, our daily builds are on the development configuration, so we are configured once a day, and for the other three we do not build automatically. Because we do it through promote. For development Configuration, we did not automatically label the SCM, and for others, we automatically label the SCM with each build.

With these, the development work began, our daily code is submitted to subversion before the end of work, the next day, the development configuration is completed automatically, and send a notification to us. We usually open a morning meeting, first we'll go to the Quickbuild page and see what changes were made yesterday, the status of the test, such as which tests were fixed, which ones haven't been fixed, and which source code did not pass the check. Then we will point to the specific report to analyze, these reports can easily open the source code, we can directly on the above to the individual changes to do code review. Usually the project takes about 30 minutes to finish.
After this development for a period of time, we have a lot of functionality is ready, can be submitted to QA as test, because the construction of the day may fail, or we specifically want to give QA, then we will choose a good build of the previous days to do promote, This promote will automatically trigger the QA configuration to do BUILD,QA configuration after the build, will send an email notification QA lead, this email quickbuild will all with the previous QA The changes of build is listed so that he knows what features are added to our version and what bugs are fixed.
After a few iterations, our development group and QA Group agreed that the basic implementation of the function, the bug is not much, so the QA lead to do a promote, triggering integration configuration does not build a large version to the customer, do VOC ( Voice of customer), listen to customers, but if the customer is not easy to see, then will be on the integration configuration to do a promote to release configuration up.

By doing this, we can basically easily know what is going on between each version, and even we can easily rebuild the version at any point in time. And, basically, we don't have to worry about when to label the SCM, because for us, all we need to see is a build of each version. And if you use subversion to manage it, you may also be able to list the changes in the SCM by command, but if one day you get dizzy and forget to label, or if you hit the wrong label, it's not so easy to find the problem. Or maybe, you can do all the functions mentioned here through a series of commands, but I think if the computer can do it, let the computer do it.

Why do you want to do continuous integration