he Continuous Integration methodology has become very important in the software development community and this is probably
The Continuous Integration methodology has become very important in the software development community and this is probably due to the effects of Agile methodologies.
On teams that have adopted such methodologies, continuous integration is one of the pillars of agility, ensuring that the entire system runs correctly on every build, even with numerous teams and high frequency of changes. But, why should we use continuous integration? What are the benefits it can provide?
Basically, the great advantage of continuous integration is the instant feedback. There are several rules for running automated builds, but the policy with more change visibility often behaves as follows: with each commit in the repository, a build is automatically triggered with all tests being executed automatically (this is called Continuous Testing), which will eventually detect errors in that moment. If a commit does not compile or “breaks” any of the tests, the team is immediately notified by e-mail, SMS or RSS indicating the cause of the faults and the commit that caused them. The team can correct the problem as soon as possible. Alternatively, there could be greater granularity rules, such as builds that are run every certain time, or that are triggered after certain types of commit, and so on.
A common practice within the continuous integration methodology is to ensure that the local build will behave the same way as in the continuous integration server. This ensures that build and test are consistent with the local server. In reality, the task of running the tests usually takes considerable time (especially if they are integrated and functional) and, usually, a great amount of tests are run locally “around” the modified code while the rest of the tests are run by the integration server.
But this does not end here, the idea is not only to run the unit, integration and functional tests with the continuous integration server, but also to be able to generate technical metrics to help improve the product quality. Tasks such as checking programming style, searching the source code for potential bugs, testing coverage and technical metrics generation are an important contribution to improve product quality. These tasks could be handled in the same way as the tests, if a metric exceeds a threshold, or the potential number of bugs found is high or if the coverage of testing is very low, a warning message (feedback) would be generated to notify the team so they can solve the problem the same way they would if a test failed or it did not compile. Such tasks are often called Continuous Inspection and, the visibility they generate, Continuous Feedback.
Furthermore, it is not only about testing and inspection, we are talking about complete builds: with each build we have a version that is theoretically ready to go into production. The project could also be installed (deploy) automatically on a development server. In a Web system, we would have the deployment of the running application with each commit, reflecting recent changes. This practice is called Continuous Deployment.
Comments? Contact us for more information. We’ll quickly get back to you with the information you need.
