Deploy rules for a small agency

The dev policy we set at Siftware in September 2014, with the release cycle I'd described in a talk that February. A small team and a handful of long-running client projects.

Deploying

• No deploys to production after 3pm on any day, or at any time on a Friday.
• Each developer works in their own branch and pushes to the test branch. Developers never push to master.
• Every test server builds itself from the test branch.
• Only two named people deploy to production.
• Deploy scripts and the process for each project live in the repo, not in someone's head.

Hotfixes were the open question: if devs never touch master, a fix branches from master, then merges back through dev, test and live.

What "done" means

Two different states, and we'd been mixing them up:

• Development complete: code finished, on test, time logged, and steps to test it written on the task.
• Signed off: the project manager has proved it works.

Developers test their own work before passing it on, and get whatever they need to do that (a test card for payment flows, say). The client receives a feature that's ready to go. They can test it, but they shouldn't have to.

The rest

• Everyone agrees the milestone dates: first deploy to test, final test for client review, staging, production.
• Thirty days of free bug fixing after a production deploy, on anything we ship.
• Everyone reports their weekly time, by project.

The cycle around it

From the talk: break the wish list into small units of work, group them into compact releases with soft deadlines, one branch per unit. A push to the dev branch runs the tests and builds the docs; a push to test also deploys to the test server; merges to live deploy semi-automatically. Support emails become tickets, and the ticket tracker becomes the wish list for the next release.

See also payments are a distributed system, where this process earned its keep, and the inherited web app checklist, where its absence is the first red flag.