Continuous integration alternatives with Orchard, Azure, and Git
What is continuous integration?
- each team member frequently integrates their work (e.g. daily)
- automated builds and tests detect integration errors
Why do we need it?
- decrease integration errors
- develop cohesive software more rapidly
- find and fix integration bugs daily
- avoid the risk of a long, arduous deferred integration
- end users frequently view and provide feedback on new features
How do we get started (i.e. what's the order of operations?)
- Get everything into source control.
- Automate the build with a single command.
- Introduce automated testing into the build (this takes time).
- Speed up the CI build.
- Hire an expert for help.
What do we need to consider when implementing it?
- Tooling is helpful not required.
- While CI requires no particular tooling,
- a Continuous Integration server (e.g. CruiseControl) is handy.
- Maintain a single source repo (e.g. at GitHub) with a version control system (e.g. Git)
- Keep everything needed to build the project in that repo (but not the build results.)
- Have a mainline branch off of which everyone creates topic branches.
- Automate the build (e.g. with MSBuild).
- Include everything need to launch the system in that build (i.e. incl. the DB schema.)
- Consider conditional builds for small changes.
- Make the build independent of any IDE's build tooling (the build must run without the IDE.)
- Make the build self-testing.
- Test Driven Development (where we write the tests before the code) is helpful but not required.
- Make sure the build fails if any of the tests fail.
- Keep in mind that automated tests are not perfect - we still need humans.
- Everyone must commit to mainline every day.
- Commit to mainline more frequently when appropriate.
- Build on the integration server after it receives each mainline commit.
- This can be manual or automatic.
- The committer isn't done until build completes successfully.
- This is not the same as a nightly build; rather, the build happens on commit not later that night.
- Immediately fix broken builds.
- This ensures that the mainline remains stable.
- "nobody has a higher priority task than fixing the build"
- [Can we automate the rejection of commits that break the build?]
- Keep the build fast.
- 10 minutes is a reasonable goal.
- If this is a problem, consider using a staged, prioritized build process with slow builds following fast, priority ones.
- Test in a clone of the production environment.
- Make the clone as similar as reasonably possible to the production env.
- Virtualization can facilitate this.
- Make it easy to clone the latest stable mainline build.
- This is important for showing clients the most recent stable iteration.
- [For web dev this could be in a staging instance of an Azure Website.]
- Make mainline status visible to all.
- e.g. build: passing
- Automate deployment.
- work branch --> mainline branch --> CI server --> staging deployment
- Automated movement from the CI server to the staging deployment
- Use automatic rollbacks if the staging deployment doesn't build.
How does it work, generally speaking?
- Checkout the mainline branch into a work branch.
- In the work branch, alter code and add/alter tests.
- Build and test the work branch.
- Merge/rebase/push to the mainline.
- Build and test the mainline branch (this is often automated on the server.)
- If the build/test fails, fix and reintegrate.
What are some options/notes re Orchard, Azure, and Git?
- Azure websites
- have automated deployment from version control
- have automated rollback on broken builds
- can deploy staging branch to staging website and master branch to LIVE website
- use .deployment and deploy.cmd files to customize your build
- Git
- really cheap branching & merging/rebasing
- everything is local, so locally building is very similar to the CI build
- Orchard CMS
- DB schema is done via code-first migrations (so it's in the source.)
- Has lots of tests already
Source