# 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.

# devops: continuous deployment infrastructure

Looking at how to handle a continuous deployment system in conjuncture with a continuous integration system. My thoughts are to use a CI system like Jenkins to automate the testing of all recently committed git repositories, and to kick off a check list of dependencies.

The general idea would be:

1. Developer commits to git/master
2. CI pulls from git/master
2.1 CI runs all regression tests against git/master
2.1.1 CI returns report to developer and halts if any fail
2.2 CI Looks up the package manifest of a given project, and pushes project to staging server
3. Staging server determines which OS project belongs under (Debian, etc) and generates debootstrap image if none exist
3.1 Staging server creates clone of debootstrap image, and apply all .deb packages from manifest to image
3.2 Staging server stores image to shared file space
4. CI calls deployment server to deploy the image to a given environment
5. Deployment server checks manifest, and determines which class of server image is to be deployed, and attempts to deploy the image to appropriate Dom0 for the given environment, as the appropriate DomU


Additional coverage testing would be included in the regression testing, and the first deployment would be to an acceptance testing environment. This setup is similar to http://morethanseven.net/2011/03/20/A-continuous-deployment-example-setup.html and other ideas by kitchensoap.com.