Ship it!: A Practical Guide to Successful Software Projects (Pragmatic Programmers) [Paperback]

"Who should read it? Most people I think. It's aimed at technical leads certainly, but all developers would benefit by reading. I believe that project managers would benefit from having high-level familiarity with the book's ideas. I thoroughly enjoyed the book: I found it a pleasure to read and was particularly impressed with the layout and organization of the material. Recommended." - Harry Newton, news@UK, September 2005

Ship It! helps teams get software out the door. Here you'll find a wealth of solid, practical advice in an easy, approachable format. You can fix many of the common problems facing software projects today with this concise introduction: you'll see the tools a successful team has to use, and learn how to use them well. You'll get quick, easy-to-follow advice on modern techniques and when they should be applied. Your team will be able to Ship It!

Jared Richardson is a developer-turned-manager who thinks a good day is having everything delegated so that he can sneak away and actually write code. He specializes in using off-the-shelf technologies to solve tough problems, especially those involving the software development process. With more that 10 years of experience, Jared has been a consultant, developer, tester, and manager, including Director of Development at several companies. He currently manages a team of developers and testers at SAS Institute, and is responsible for a company-wide effort to use test automation to improve the quality of SAS products. Will Gwaltney is a software developer with over 20 year's experience. In that time he hasn't quite seen it all, but he's seen most of it (and a lot of it hasn't been pretty). He's worked at both large companies and start-ups in the fields of electronics CAD, networking, telecommunications, knowledge representation, and web-based planning and scheduling for the enterprise. Will currently works on test automation at SAS Inc., the largest privately-owned software company in the world.

Develop in a Sandbox

How do you share code with your teammates? A surprising number of teams never answer this question explicitly and instead just get a big, old shared disk drive, with all of their source code and other files lying around. Any act by any developer—from simply editing a file to compiling code—will instantly affect every other developer on the team. Their life is now filled with constant, unpleasant surprises.

It’s just like a crowded kitchen on Thanksgiving, with everyone throwing something else into the mix, and it makes for a pretty frustrating work environment. While many teams continue to operate this way, you can take a safer and more professional stand. This will have a deep effect on your tools and infrastructure, so you need to get this straight right from the beginning.

There’s only one fundamental rule to keep in mind: isolate others from the effect of your work until you are ready. That’s why we call this sandbox development: every developer has their own sandbox to play in without disturbing other developers.

That may sound easy enough, especially in terms of isolating source code (see Practice 2, Manage Assets, on page 19), but the real trick is to remember that it applies to all resources: source code, database instances, web services on which you depend, and so on.

Your own development machine should be designed to contribute to your own productivity.1 It should not contribute anything to the global build process—no one else should have to rely on your machine directly for anything.

But how do other developers get your code? Code is shared via the repository. Think of the repository as a big shared disk, but one that’s repository managed by a librarian. The librarian ensures that everyone has the right version of any file (or other resource) that they need and that everyone can work without clobbering each other. Every developer uses a software tool to check in and check out files (just like a real book library) so they can work on them locally.

On your own developer machine, you edit local copies of source code files, compile, build, and test in splendid isolation from your team-1This means it’s perfectly okay for different developers to use different code editors or even Integrated Development Environments (IDEs).mates. If you need to use a database, a web server, or any other resource while developing, make sure that you’re the only one using it. When you’re satisfied that you’re finished with a piece of code, you check it back into the repository.

But then how do customers get the finished product? In addition to the developer machines and the repository, you have a build machine. The build machine is an unattended server that simply gets all of the latest source code from the repository, builds, and tests it, over and over again. The result of this build is the product release.

Most of the time, this release will just be thrown away after each build, but every so often this is the pile of bits that you’ll ship to your customers and end users. It’s built the same whether it’s the usual 10:00 a.m. build or it’s the final release after months of toil and sweat.

It’s always consistent, because the build machine is an independent entity: it never looks at individual developer machines for any reason. The input to the build is the repository, and the output from the entire process is from a designated build machine. This system works great as long as developers don’t cheat.

Sometimes it’s hard to "stay in the sandbox," especially if database licenses or web server ports are in short supply. You may be able to use a single database but create separate instances for each developer. Or, if forced to use one database with one instance, you may be able to partition the data space (for example, Joe is assigned test account data for accounts 1000–1999, and Sue is assigned accounts 2000–2999, and so on). This still leaves you open to risk of interference, but it’s better than nothing.

For other resources such as web services, every developer should have a clear shot at their own instance (whether they are providing the service or testing against it).

With this basic idea of isolation in mind, let’s take a look at some of the tools and other bits of infrastructure you’ll need to achieve the sandbox effect.