Continuous integration is the practice of merging the code of multiple software developers several times a day. This is a foundation for agile development and continuous delivery whereby code is incrementally developed, built, deployed and tested such that it is regularly available for release. The following are basic principles of continuous integration.
Short Development CyclesOrganize work into short development cycles that produce working functionality.
Version ControlUse of a version control tool that provides versioning and a history of builds and files.
Everyone Commits DailyIn principle, all developers commit working code to a shared baseline each day.
Every Commit is Built & TestedEvery commit to the baseline triggers a build. Developers unit test their code in the common build.
Fix Broken Builds ImmediatelyFixing broken builds is prioritized as there are more code changes coming at a continual pace and things get messy if build problems pile up.
Rapidly Detect ProblemsThe entire philosophy behind continuous integration is that problems should be detected as early as possible. This principle can be applied in countless ways. For example, automated regression tests may be organized such that commonly broken functions are tested first.
Automate the BuildThe build is automated and designed for speed.
Automate TestingToil is reduced by automating testing where possible including build testing, unit testing and automated acceptance testing that includes regression tests.
Automate DeploymentEnvironments can be deployed with the press of a button. In some cases, deployment is automatically triggered by criteria such as a green light in automated testing.
Use a Deployment PipelineTesting environments progress from those that are completely unstable and changed several times a day to environments such as user acceptance testing and production staging that are deployed less often to provide a stable environment for testing. The following is a typical deployment pipeline process.
Test Reflects ProductionEvery effort is made to have test environments such as UAT reflect production, often at reduced scale. This includes elements such as platforms, systems, infrastructure, architecture and data.
Builds are TransparentEveryone can see what a build contains including a list of implemented requirements and/or fixed defects.
Builds are AvailableEveryone can access a build. For example, a user acceptance testing team can access an environment with the latest build at any time.
This is the complete list of articles we have written about coding.
If you enjoyed this page, please consider bookmarking Simplicable.
ReferencesFowler, Martin, and Matthew Foemmel. "Continuous integration, 2006." URL http://martinfowler. com/articles/continuousIntegration. html (2012).
© 2010-2023 Simplicable. All Rights Reserved. Reproduction of materials found on this site, in any form, without explicit permission is prohibited.
View credits & copyrights or citation information for this page.