CSC/ECE 517 Spring 2013/ch1b 1m yk: Difference between revisions
| (5 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
<big>'''Continuous Integration'''</big> | <big>'''Continuous Integration'''</big> | ||
Updated and Changed From | |||
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch6_6f_jd http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch6_6f_jd] | |||
and | |||
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch6_6f_va http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch6_6f_va] | |||
__TOC__ | __TOC__ | ||
==Introduction== | |||
Continuous integration (CI) was first proposed as part of extreme programming. It aims to prevent costly integration problems through the daily integration of developer code. CI was originally seen as an extension of test driven development, where all unit tests would be run before the integration of code to the mainline. It has since evolved to a system where daily integration of code is facilitated by the heavy use of automated testing and build servers which report results back to developers. | |||
==Definition== | ==Definition== | ||
| Line 7: | Line 15: | ||
[http://en.wikipedia.org/wiki/Continuous_integration Continuous Integration] is a software development practice where members of a team integrate their work frequently. This approach leads to significantly reduced integration problems and allows a team to develop [http://en.wikipedia.org/wiki/Cohesion_(computer_science) cohesive] software more rapidly | [http://en.wikipedia.org/wiki/Continuous_integration Continuous Integration] is a software development practice where members of a team integrate their work frequently. This approach leads to significantly reduced integration problems and allows a team to develop [http://en.wikipedia.org/wiki/Cohesion_(computer_science) cohesive] software more rapidly | ||
==How does CI work?== | ==How does CI work?== | ||
| Line 16: | Line 21: | ||
The above diagram shows an overview of a simple CI environment, which will give us a good idea of how CI works. <ref name="CIRef2">Thomas Jaspers. "Continuous Integration – Overview" http://blog.codecentric.de/en/2009/11/</ref>.In order to apply quality control throughout the project, CI requires members of the team integrate their work into the main code repository at least daily, which leads to multiple integrations per day. Each developer will first build and run all the tests locally to ensure all the changes are good, then commit the changes to the repository using some version control tools, such as Subversion. Once the CI sever detects the new commits, it will kick out an automated build that runs all the automated tests that could detect compile/integration errors as quickly as possible. If the automated build fails, the team will be notified and required to resolve the error immediately. In addition, at least once every 24 hours, a nightly build will be executed to ensure the quality of the code in the main repository. <ref name="CIRef5">Laurie Williams. "Scrum + Engineering Practices: Experiences of Three Microsoft Teams" http://collaboration.csc.ncsu.edu/laurie/Papers/ESEM11_SCRUM_Experience_CameraReady.pdf</ref> | The above diagram shows an overview of a simple CI environment, which will give us a good idea of how CI works. <ref name="CIRef2">Thomas Jaspers. "Continuous Integration – Overview" http://blog.codecentric.de/en/2009/11/</ref>.In order to apply quality control throughout the project, CI requires members of the team integrate their work into the main code repository at least daily, which leads to multiple integrations per day. Each developer will first build and run all the tests locally to ensure all the changes are good, then commit the changes to the repository using some version control tools, such as Subversion. Once the CI sever detects the new commits, it will kick out an automated build that runs all the automated tests that could detect compile/integration errors as quickly as possible. If the automated build fails, the team will be notified and required to resolve the error immediately. In addition, at least once every 24 hours, a nightly build will be executed to ensure the quality of the code in the main repository. <ref name="CIRef5">Laurie Williams. "Scrum + Engineering Practices: Experiences of Three Microsoft Teams" http://collaboration.csc.ncsu.edu/laurie/Papers/ESEM11_SCRUM_Experience_CameraReady.pdf</ref> | ||
==Principles of Continuous Integration <ref name=" | ==Principles of Continuous Integration <ref name="CIRef3">James Betteley. "Principles of Continuous Integration" http://devopsnet.com/2011/01/25/principles-of-continuous-integration/</ref>== | ||
===Fix Build Failures Immediately=== | ===Fix Build Failures Immediately=== | ||
A developer must never leave a build broken. If a build does break, the build team should be within their right to roll back the last commit. | A developer must never leave a build broken. If a build does break, the build team should be within their right to roll back the last commit. | ||
| Line 27: | Line 32: | ||
===Code Should be Built and Tested Before Check In=== | ===Code Should be Built and Tested Before Check In=== | ||
This is accomplished through either a local build or a | This is accomplished through either a local build or a Version Control (VC) system implementing Continuous Integration that can perform pre-commit builds. | ||
===Easily Accessible Results=== | ===Easily Accessible Results=== | ||
| Line 80: | Line 85: | ||
==References== | ==References== | ||
<references/> | <references/> | ||
Latest revision as of 00:05, 26 February 2013
Continuous Integration
Updated and Changed From http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch6_6f_jd and http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch6_6f_va
Introduction
Continuous integration (CI) was first proposed as part of extreme programming. It aims to prevent costly integration problems through the daily integration of developer code. CI was originally seen as an extension of test driven development, where all unit tests would be run before the integration of code to the mainline. It has since evolved to a system where daily integration of code is facilitated by the heavy use of automated testing and build servers which report results back to developers.
Definition
"We keep our code ready to ship"
Continuous Integration is a software development practice where members of a team integrate their work frequently. This approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly
How does CI work?
The above diagram shows an overview of a simple CI environment, which will give us a good idea of how CI works. <ref name="CIRef2">Thomas Jaspers. "Continuous Integration – Overview" http://blog.codecentric.de/en/2009/11/</ref>.In order to apply quality control throughout the project, CI requires members of the team integrate their work into the main code repository at least daily, which leads to multiple integrations per day. Each developer will first build and run all the tests locally to ensure all the changes are good, then commit the changes to the repository using some version control tools, such as Subversion. Once the CI sever detects the new commits, it will kick out an automated build that runs all the automated tests that could detect compile/integration errors as quickly as possible. If the automated build fails, the team will be notified and required to resolve the error immediately. In addition, at least once every 24 hours, a nightly build will be executed to ensure the quality of the code in the main repository. <ref name="CIRef5">Laurie Williams. "Scrum + Engineering Practices: Experiences of Three Microsoft Teams" http://collaboration.csc.ncsu.edu/laurie/Papers/ESEM11_SCRUM_Experience_CameraReady.pdf</ref>
Principles of Continuous Integration <ref name="CIRef3">James Betteley. "Principles of Continuous Integration" http://devopsnet.com/2011/01/25/principles-of-continuous-integration/</ref>
Fix Build Failures Immediately
A developer must never leave a build broken. If a build does break, the build team should be within their right to roll back the last commit.
Improve With Every Check In
Each check-in should add value to the codebase.
No Check Ins on a Broken Build (unless fixing)
The cause of the original breakage may be difficult to identify as more code is added to the broken code.
Code Should be Built and Tested Before Check In
This is accomplished through either a local build or a Version Control (VC) system implementing Continuous Integration that can perform pre-commit builds.
Easily Accessible Results
The results of the CI system should be easily visible to everyone on the development team including project managers and testers.
Light Weight Check Ins
It is important to provide the developer with quick feedback upon code check-in. Keeping the complete test bucket relegated to nightly builds is recommended.
Advantages
Reduced risks. By integrating many times a day, you can reduce risks on your project. Doing so facilitates the detection of defects, the measurement of software health and a reduction of assumptions.
- Defects are detected and fixed sooner.
- Health of software is measurable.
- Reduce assumptions.
Continuous Integration provides a safety net to reduce the risk that defects will be introduced into the code base. The following are some of the risks that Continuous Integration helps to mitigate:
- Lack of cohesive, deployable software
- Late defect discovery
- Low-quality software
- Lack of project visibility
Reduced repetitive manual processes. Reducing repetitive processes saves time, costs and effort. These repetitive processes can occur across all project activities, including code compilation, database integration, testing, inspection, deployment and feedback. By automating Continuous Integration, you have a greater ability to ensure all of the following.
- The process runs the same way every time.
- An ordered process is followed. For example, you may run inspections (static analysis) before you run tests-in your build scripts.
- The processes will run every time a commit occurs in the version control repository.
Generate deployable software at any time and at any place. Continuous Integration can enable you to release deployable software at any point in time. From an outside perspective, this is the most obvious benefit of Continuous Integration. With Continuous Integration, you make small changes to the source code and integrate these changes with the rest of the code base on a regular basis. If there are problems, the project members are informed and the fixes are applied to the software immediately.
Enable better project visibility. Continuous Integration provides the ability to notice trends and make effective decisions, and it helps provide the courage to innovate new improvements. Projects suffer when there is no real or recent data to support decisions, so everyone offers their best guesses. Typically, project members collect this information manually, making the effort burdensome and untimely. The result is that often the information is never gathered. A Continuous Integration system can however provide just-in-time information on the recent build status and quality metrics. Some Continuous Integration systems can also show defect rates and feature completion statuses. Because integrations occur frequently with a Continuous Integration system, the ability to notice trends in build success or failure, overall quality and other pertinent project information becomes possible.
Establish greater confidence in the software product from the development team. Overall, effective application of Continuous Integration practices can provide greater confidence in producing a software product. With every build, your team knows that tests are run against the software to verify behavior, that project coding and design standards are met, and that the result is a functionally testable product. Since a Continuous Integration system can inform you when something goes wrong, developers and other team members have more confidence in making changes. Because Continuous Integration encourages a single-source point from which all software assets are built, there is greater confidence in its accuracy.
Disadvantages
Increased overhead in maintaining the Continuous Integration system. This is usually a misguided perception, because the need to integrate, test, inspect and deploy exists regardless of whether you are using Continuous Integration.
Too much change. Some may feel there are too many processes that need to change to achieve Continuous Integration for their legacy project. An incremental approach to Continuous Integration is most effective; first add builds and tests with a lower occurrence (for example, a daily build), then increase the frequency as everyone gets comfortable with the results.
Too many failed builds. Typically, this occurs when developers are not performing a private build before committing their code to the version-control repository. It could be that a developer forgot to check in a file or had some failed tests. Rapid response is imperative when using Continuous Integration because of the frequency of changes.
Additional hardware/software costs. To effectively use Continuous Integration, a separate integration machine should be acquired.
Developers should be performing these activities. Sometimes management feels that Continuous Integration is just duplicating the activities that developers should be performing anyway. Yes, developers should be performing some of these activities, but they need to perform them more effectively and reliably in a separate environment. Leveraging automated tools can improve the efficiency and frequency of these activities.
References
<references/>