• Next: Ten-Minute Build
• Previous: No Bugs
• Up: Chapter 7: Releasing

in 99 words

To support collective ownership, use a concurrent model of version control. Support time travel by storing tools, libraries, documentation, and everything else related to the project in version control. (On-site customers' files, too.) Keep the entire project in a single repository.

Avoid long-lived branches, particularly for customized versions; they'll cripple your ability to deliver on a timely schedule. Instead, use configuration files and build scripts to support multiple configurations.

Keep your repository clean: never check in broken code. All versions should build and pass all tests. "Iteration" versions are ready for stakeholders; "release" versions are production-ready.

Rant

Paranoia, Control, and $30,000 of Tooling

Section Outline

• Version Control
• Sidebar: Version Control Terminology
• Concurrent Editing
• Time Travel
• Whole Project
• Customers and Version Control
• Keep It Clean
• Single Codebase
• Appropriate Use of Branches
• Questions
  • Which version control system should I use?
  • Should we really keep all our tools and libraries in version control?
  • How can we store our database in version control?
  • How much of our core platform should we include in version control?
  • With so many things in version control, how can I update quickly when I need to?
  • How should we integrate source code from other projects? We have read-only access to their repositories.
  • We sometimes share code with other teams and departments. Should we give them access to our repository?
• Results
• Contraindications
• Alternatives
• Further Reading

Full Text

This section will go online later this year. In the meantime, why not buy the book?

• Next: Ten-Minute Build
• Previous: No Bugs
• Up: Chapter 7: Releasing