The one thing missing from this guide right now is tracking work in an Agile way. I plan to add that later.


Local Development Cycle

Release small often

  1. Pull and rebase latest code from mainline.
  2. Work from a short-lived feature branch.
  3. Unit test, frequently commit locally, push feature branch when it passes tests.
  4. Integrate latest mainline locally, run private build/tests, push.
  5. Final push, create a pull request.

Pull Requests and Code Reviews

No unreviewed code

  • Another developer reviews the PR (code review)
  • PR merges into mainline

Continuous Integration

Build once, deploy-to-many

  • CI Server is triggered by source control changes.
  • Build Triggered by mainline and feature branch changes. Build in clean environment, run unit tests, create deployment package.
  • Integration Always runs and fully automated. Environment is created and deployed to from scratch. Automated integration tests run. Jeffrey Palermo calls this the TDD stage.
  • UAT There are many kinds of UAT environments: QA, user acceptance, security, performance. Runs if mainline changes and Integration succeeds. Existing environments deployed to. Some automated testing.
  • Prod Runs if UAT succeeds and deployment is approved. Existing environment deployed to. Some automated smoke testing. Can require approval.

Aspects of quality code

Code is never finished

  • Loosely coupled Dependencies are reduced. See SOLID, DRY, YAGNI.
  • Complexity reduced Packages, classes, methods have one purpose.
  • Tested early Unit testing reduces defects and improves architecture. See TDD.
  • Reviewed Code reviews improve quality and share knowledge.
  • Clearly named Naming (of classes, methods, variables) is hard and important.
  • Self-documenting What the code does should be obvious. Comment why the code does what it does, when not obvious.
  • Properly versioned Harder than it seems. See Semantic Versioning and your language's package peculiarities.
  • Maintanable and replaceable No code lasts forever. Design for change.

Capabilities of high-performing software teams

A couple of principles can guide making lots of better decisions.

  1. Reduce friction to doing the right thing
  2. Do all the steps

Here are the 24 capabilities of high-performing software organizations from the DORA group's meticulous, evidence-based research.

Capability (and desired result)
01 Version control
02 Deployment automation
03 Continuous integration (CI)
04 Trunk-based development
05 Test automation
06 Test data management
07 Shift left on security (put first, make easy)
08 Continuous delivery (CD)
09 Loosely coupled architecture
10 Empowered teams
11 Customer feedback
12 Value stream mapping
13 Working in small batches
14 Team experimentation
15 Change approval processes (lightweight, not external)
16 Monitoring
17 Proactive notification
18 WIP limits (limit work-in-progress)
19 Visualizing work (public Kanban boards)
20 Westrum organizational culture (Generative)
21 Supporting learning
22 Collaboration among teams
23 Job satisfaction
24 Transformational leadership

The Four Key Metrics

How do you know you're succeeding?

Again, from the DORA group.

  • Deployment Frequency How often an organization successfully releases to production
  • Lead Time for Changes The amount of time it takes a commit to get into production
  • Change Failure Rate The percentage of deployments causing a failure in production
  • Time to Restore Service How long it takes an organization to recover from a failure in production