Home :: Agile-Book :: version_control

(book cover)

Order it now!

Welcome to the The Art of Agile Development website. Think of this as the "special features" DVD for the book, only without the DVD. (If you haven't bought the book yet, that's okay... we won't tell if you don't.) Here, you'll find a cornucopia of bonus material, such as downloadable posters, behind-the-scenes material, and new insights.

For more bonus material, see the table of contents. New entries are posted every Wednesday.

(If there's nothing else on this page, this chapter has yet to be posted. Try the table of contents instead.)

 Print

The Art of Agile Development: Version Control

by James Shore

23 Jul, 2008

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.

Inside The Book

  • 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

Rant

There's a difference between version control and software configuration management (SCM). What's SCM, you ask? Well, the cynic in me says it's the price: version control systems (like CVS, SVN, Mercurial, and Git) are free; software configuration management systems (like Perforce, PVCS, and ClearCase) cost big bucks.

Don't get me wrong. I think it's important to be in control of exactly what software is deployed at any moment, to be able to roll it back in case of trouble, and to deploy only the features that are ready to be deployed. That's really what software configuration management is all about.

But the tools don't seem to be up to the task. Other than basic, plain-vanilla version control, real SCM requires that you manage interactions with third party components such as OS patches and library versions, database schemas, porting and back-porting data, and so forth. These require human judgment, which tools can't provide.

So instead, "SCM" systems are just glorified version control systems. They make up for their name and high price by putting "management controls" around version control, providing all kinds of admin controls to restrict who can do what, when. Sometimes they tack on bug and task trackers, too.

This "management" doesn't actually help you get closer to the goal of deploying and rolling back software; it just lets you play God with admin priviledges. One company used their SCM tool to enforce check-in comments. If you didn't provide at least a three-word comment with your check-in, it wouldn't go through. The most common check-in comment? "a a a." (The second-most common: "z z z.")

That's not management; it's paranoia and coercion... the opposite of good management. Real management is about hiring good people, giving them the resources and context they need, and trusting them to do their job. It's not forcing people to type in three words every time they check in. It's not linking every bug to a specific developer's check-in so you know who to blame.

Now, I'm no SCM expert and it's possible that I've missed something. But I'm going to take a risk here and shout the facts I see: the emperor has no clothes! The concept of SCM is important: we need to deploy software that works, incrementally deploy new features, and successfully roll back if something goes wrong, and we need to take our data with us in each direction. The sales job of SCM is an appeal to paranoia, control, and the hope that $30,000 of tooling can replace $100,000 of competent programmer.

It's the eternal dream: hope that tools and processes will substitute for individual judgment and expertise. Dream on.


Loading...

Home :: Agile-Book | Comments (...)

Loading comments...