13   Keep It Releasable

“We just found a showstopper that you need to fix right away. Stop what you’re doing, and go ahead and make the fix; don’t bother with the usual procedures. No need to tell anyone else about it—just get going. Hurry.”

It sounds innocent enough. A critical fix needs to be checked in. It’s a small thing, and the need is urgent, so you agree to take care of it.

The fix goes smoothly. You check in the code and return to your original, high-priority task. Then the screaming begins. Too late, you realize that a fellow developer has checked in an incompatible change, and now you’ve rendered the system unusable for everyone. It’s going to take a lot more work (and time) to get the system back to a releasable state. Now you’re stuck! You’ll have to tell everyone you can’t deliver the fix as you promised. And the devil laughs, “Bwahahahaha!”

Now you’re in a bad position: the system is unreleasable. You’ve suddenly created risk and created an opportunity for bad things to happen.

In 1836, General Antonio López de Santa Anna, then president of Mexico, charged his way through west Texas, sending General Sam Houston and his men on the retreat. When Santa Anna reached the banks of the Buffalo bayou (in southeast Texas), he ordered his troop to rest. The legend says that he was so confident he did not bother to post sentries. When General Houston decided to charge late that afternoon, Santa Anna’s army did not even have the time to form up. They lost this decisive battle, changing Texas forever.^[14]

Anytime you are unprepared is the perfect time for the enemy to strike. Think about it: how often does your application slip into a nonreleasable state? Does your code in the repository appear like Santa Anna’s army on that fateful afternoon—not in formation and unable to execute at a moment’s notice?

When working in a team, you have to be sensitive to the changes you make, constantly keeping in mind that you affect and influence the state of the system and the productivity of the whole team. You wouldn’t tolerate someone littering the kitchen area at the office. Why would you tolerate someone trashing your project’s code?

There’s a simple workflow to follow to make sure you don’t check in broken code:

Run your local tests.

Begin by making sure the code you’re working on compiles and passes all of its unit tests. Then make sure all of the other tests in the system pass as well.

Check out the latest source.

Get the latest copy of the source code from the version control system, and compile and test against that. Very often, this is where a surprise will show up: someone else may have made a change that’s incompatible with yours.

Check in.

Now that you have the latest version of code compiling and passing its tests, you can check it in.

Now during that process, you may discover a problem—someone else may have checked in code that does not compile or pass its tests. When that happens, let them know right away—and possibly warn the rest of the team if need be. Or, even better, have your continuous integration system point it out automatically.

Now that might sound a bit intimidating, but it shouldn’t. Continuous integration systems are simply applications that check out, build, and test your code constantly in the background. They are easy enough to cobble together yourself using scripts, but you get more features and stability with an existing free, open-source solution. You might want to take a look at Martin Fowler’s article^[15] or Mike Clark’s book, Pragmatic Project Automation. How to Build, Deploy, and Monitor Java Applications [Cla04], for all the details.

Looking forward a bit, suppose you hear about an upcoming significant change that may break the system. Don’t just let it happen—take the warning seriously, and explore ways you can avoid disrupting the system when the check-in happens. Consider options that will help you introduce and transition those changes smoothly so the system is available for continual testing and feedback as the development proceeds.

Although it’s important to keep the application releasable, it’s not always that easy. For instance, consider a change to the database schema, an external file format, or a message format. Changes such as these often affect large parts of the application and can render it unusable until a significant amount of code is changed. However, you have options to ease that pain.

Version the database schema, the external files, and so on, as well as the APIs that reference it, so that all related changes can be tested. This versioning isolates your changes from the rest of the code base so other aspects of the application can continue to be developed and tested.

You can also branch the code in your version control system to address these issues (but branch with care; wild branching causes more problems than it solves. See Pragmatic Version Control Using CVS [TH03a] and Pragmatic Version Control Using Subversion [Mas06] for details).

Keep your project releasable at all times. Ensure that the project is always compilable, runnable, tested, and ready to deploy at a moment’s notice.

What It Feels Like

You feel confident that anytime the boss, the chairman of the board, QA, a customer, or your spouse comes by the office to visit, you can show them the latest build of the software without hesitation. Your project is simply always in a ready-to-run, stable state.

Keeping Your Balance

• Sometimes you can’t invest the time and energy needed to keep the system in a releasable state throughout a major set of changes. If it would take a month’s effort just to keep the application available throughout a week’s worth of changes, then go for the week of downtime. But this should be the exception, not the rule.

• If you must render the system unreleasable for an extended period, have a branched version (of code and schema) you can still continue to experiment with—and fall back on. Do not render the system unreleasable and irreversible as well.