Continuous Integration: Developer Commit and Staging Flow
The Flowchart outlines a simple path in which a developer committing to branch breaks the regressions tests, triggering the CI server to lock the repository from subsequent commits. The expectation is that the developer will be notified via build report that the branch is effectively broken, and they must ensure that their subsequent commit will pass all regression tests (note, the developer should be running regression tests against their branch before merging into the master, but not everyone will remember this). The SCM will be unlocked by some mechanism, be it a particular message indicating that the subsequent commit will fix it, re-opening the SCM to commits.
A successful regression test will trigger the SCM to be locked until the current build it successfully deployed. The staging server will create a new chroot image based on a meta file containing all software packages, creating said software packages from the most recent commit to the SCM.
Upon successful stage, the CI server will request from the Deployment server that this new chroot environment be deployed to whatever environment (QA, Testing, Production, etc) for any subsequent User Acceptance testing, or for the truly brave, live production.
Once deployed, the CI server will unlock the SCM, allowing developers to commit more merges into the master branch, thus triggering this process over again.
Categorised as: devops, Programming, System Administration