Welcome to Shaun Luttin's public notebook. It contains rough, practical notes. The guiding idea is that, despite what marketing tells us, there are no experts at anything. Sharing our half-baked ideas helps everyone. We're all just muddling thru. Find out more about our work at bigfont.ca.

Continuous integration alternatives with Orchard, Azure, and Git

Tags: orchard-cms, azure, azure-websites, git, github

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?)

  1. Get everything into source control.
  2. Automate the build with a single command.
  3. Introduce automated testing into the build (this takes time).
  4. Speed up the CI build.
  5. 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?

  1. Checkout the mainline branch into a work branch.
  2. In the work branch, alter code and add/alter tests.
  3. Build and test the work branch.
  4. Merge/rebase/push to the mainline.
  5. Build and test the mainline branch (this is often automated on the server.)
  6. 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