How We XP: Develop & Deploy

I’m not going to go into planning. That’s another post.

I’m going to assume that stories — the work that is to be done — are broken into small, individually-acceptable pieces of work. “Acceptable” means that a Product Manager (PM) can verify that developers did the agreed work completely. Keeping the stories small means it is easier to make progress, show progress, and validate progress.

I’m also assuming that the team is using git for version control, the developers are test-driving their code (Test-driven Development or TDD), the current test suite is green on a Continuous Integration system (CI), and that we are talking about a web app.


  • All new development is done locally

Continuous Integration (CI)

  • Your git repo should have a post-commit hook that starts a CI build. On every push to master, no exceptions.

Staging (aka Acceptance)

  • Staging is a deployment (or environment) that looks exactly like Production, with the same versions of OS, database, etc.


  • Production is where the shipping product lives.

Other Deploys

This list is by no means exhaustive. But small-to-medium-sized projects tend to have one or more of these deploys.

  • Patch Staging: A copy of Staging, meant as a short-lived deploy just to verify a hot-fix. Using a second Staging means mainline work doesn’t slow down while a patch is developed and shipped. Same rules as Staging apply, but tear this deploy down as soon as the fix is deployed to Production.

Not Scary

  • Continuous Delivery: What’s described above is really Continuous Delivery — insist that code always move in one direction: towards Production. Also, set up the whole team so that it’s easier to move towards Production and release often.
  1. Developers branch from the last Production deploy version.

Sometimes Scary

  • Continuous Deployment: Some teams are able to push every green build to Production. I’m not going to cover this in this post. But there is additional process and code needed to support this.


These are the things you should truly worry about.

  • Long test suites: when your test suite or CI pipeline is too long, you run the risk of completing work faster than you can verify it. If you keep locally-run suites fast — say, under 10–20 minutes — then your developers can get features to staging multiple times a day. Long CI pipelines are less awful. For example, a web app can have a multi-stage pipeline that puts an all-browser compatibility suite near the end. Main development can continue based on success of unit tests, collaboration tests, and one browser stage of tests. Then the multi-browser suite can run once or twice a day, and browser-based problems from that stage can be bugs that get prioritized against other work.

You may know me from such projects as Jasmine: BDD for JavaScript, P is for Pivotal Labs and Gee, Your Pork Butt Smells Terrific

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store