Continuous integration (CI) is the practice of regularly merging code changes into a shared repository. With CI, developers merge their code changes daily, which helps prevent integration issues. Automated unit tests are run on the merged code to catch any errors or failures. If all tests pass, the changes are committed to the main codebase. As code is built on the CI server, releases are automatically deployed to test, staging, and production environments on a scheduled basis. The goals of CI are to frequently integrate changes, catch errors early, and automate testing and deployments.

1. Continuous Integration WorkflowContinuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day. The main aim of CI is to prevent integration
problems. CI was originally intended to be used in combination with automated unit tests written through the practices of test-driven development. The developer executes automated tests
against his code, and if they all pass they are committed to the mainline. This helps avoid one developer's work-in-progress breaking another developer's copy. As the codebase builds on the CI
server, releases are then automatically deployed (on an agreed schedule) to the test environment. If tests are successful automated deployments are made to Staging and Production servers.
· Maintain a code repository
· Automate the build
· Make the build self-testing
· Everyone commits to the baseline every day
· Every commit (to baseline) should be built
Development
Team (Scrum)
Stakeholders
Source Control
(Development Server)
CI Server
Continuous Integration
(Incremental Builds)
Test
Stage/Regression
Production
Sprint
Demos (UAT)
Automated Unit &
Assembly Tests
Automated
SFT/SIT Tests
Automated
Pre-Production
Deployment Tests
Automated Deployments
Automated Deployments
Autom
ated Deploym
ents
Automated
Post Deployment
Regression Tests
Completed
Release
Completed
Release
Completed
Release
Queued
Releases
A
C
B
D
E
F
G
H
Automated Builds
Tested
Code
Completed
Code
Continuous Reviews
X=1
· Keep the build fast
· Test in a clone of the production environment
· Make it easy to get the latest deliverables
· Everyone can see the results of the latest build
· Automate deployment
Best Practices
A
Stakeholders are represented by the Product Owner are effectively
performing UAT at the end of every Sprint.
B
Sprint Demos are where the Stakeholders review progress on a
continuous basis.
C
Development teams receive continuous feedback from Stakeholders
through the Product Owner and the Sprint Demos.
D
Source code management and automated unit and assembly testing is
performed, and then code is automatically deployed to the CI server.
E
Completed code is queued on the CI server until the Release Manager
decides to proceed with promotion to Test.
F
Automated SFT (System Functional) and SIT (System Integration) testing
occurs.
G
The Release Manager determines the scheduled to automatically deploy to
Staging for pre-deployment regression and performance testing.
H
The final step is for the Release Manager to schedule the automated deployment
to Production, where post production regression tests may be performed.
Prepared By: Nigel Thurlow
Last Updated: 10th
April 2015
Version: 1