On the Importance of Development-and-Build Environments

Brian Alexander Lee

June 2007

Updated December 2007

Summary: A mature development-and-build process no longer is a luxury. (5 printed pages)

Contents

Introduction
Four Keys for Development-and-Build Environments
Conclusion
Critical-Thinking Questions
Sources
Further Study
 

Introduction

Here is a common scenario for a small project that grows quickly. Because the project is small, there is no development-and-build environment policy; so, whenever a build is required, some unlucky soul draws the short straw and gets to package everything up and deploy to a test server. The test server goes by different names in different companies—demo, test, prep—but it serves the same function. For a small project, this is a small effort—only a few hours every time that some vice president or other suit wants to see a version.

But, as a project grows up, starts making money, and gets more resources and more demands, the amount of time that is spent on running builds and deploying increases exponentially. So, that short straw that meant a few hours of tedium becomes a full-time job to run builds for parallel code branches, and perform demo environments and customer-support environments and sales environments. Without a development-and-build process, it is not uncommon to spend up to 15 percent of your time running builds and debugging problems that come up. Creating and implementing this process frees up brainpower from the mundane work of build and environments.

It Was the Worst of Times

On the first JEE (Enterprise Java) project on which I worked as a young developer, way back in 2001, we did not have a build process. We checked our .java files into the Microsoft Visual SourceSafe version-control system, and developers updated their snapshots only when they had to. Most programmers developed on Windows with a mix of IDEs (JBuilder, JDeveloper, VisualCafe, and VisualAge for Java). When it was time for a release, a build engineer tried to run a build and then copy everything over to a test server running Solaris. Every time that we got to the build stage, it took weeks of late nights and weekends to fix compilation problems—problems from differences between operating systems and Java runtime environments (JREs) and general issues from running a build only every few months of development.

It Was the Best of Times

On my last JEE project, I had the pleasure of working on a project on which a configuration-management architect had spent a lot of time on our build and deployment process. He used Apache Ant, CruiseControl, and a lot of shell scripting to automate the build, so that it ran every hour, ran JUnit tests, sent e-mails upon success or failure, and deployed to a test server. All of this happened "automagically," and the pain of the memory of my first JEE project quickly faded. I could not remember the last time that I spent trying to debug someone else's compilation error. And there was no hassle deploying to a server, because we could cut a release from every hourly build. There was no manual build massage to get a product release that customers could use.

Unfortunately, that brilliant architect moved on to a new company, and the magic began to fade. No one was really left to carry the torch, so the automated build and deployment system was passed from programmer to programmer and, eventually, devolved into a set of manual processes that consumed the time of several configuration-management specialists just to keep up with build and deployment.

As a maturing project, we had three or four code lines in parallel development and two dozen or so test environments (for all of those code lines). Our configuration-management team really missed that "automagic."

Four Keys for Development-and-Build Environments

This scenario really brought to light the main reason for creating a build-and-development strategy, and sticking to it: If you do not, you will spend a lot of money on build-and-development environments.

Test Early and Often

It does not really matter what kind of framework you work with; you will always have integration issues, when moving from a developer's desktop to a test or production server. So, whether it's Java and you are moving code from a developer's Windows workstation to a Unix test server, or whether it's .NET and you're moving code from a developer's Windows XP workstation to a Windows 2003 test server, there will be something that needs testing. The longer that you wait to build and test, the harder that it is to track down who introduced a bug. If you cannot track down who introduced a bug, it will take longer and be more expensive to fix. If you can identify these problems immediately, you can have the same developer fix what they broke quickly.

Use Tools to Automate

Developers also will spend a lot of time setting up their local build-and-development environment. I was visiting a group of Java developers and became frustrated when they were all using Textpad and Notepad to edit Java source files. So, they kept missing easy validation and searches. I showed them my laptop that both Eclipse and IntelliJ set up to compile automatically, check for documentation and style errors, and many other time savers. But the developers said that they could not figure out how to set up an Eclipse project to compile properly. They needed an automated script to create a workspace. This seems like a luxury; but, when you consider the alternatives—hours of setting up workspaces, or hours wasted using basic text editors—creating an automated script to set up a development environment makes sense.

Many mundane tasks can be automated by using open-source tools like Apache Ant (or NAnt, for the .NET side of the world). So, this means that they should be automated. Douglas Merrill, VP of engineering at Google, says, "Our goal is to automate as many things as we can, because it makes un-fun things not happen. Nobody wants to have a boring job—right?" Mr. Merrill is right, and not just about the un-fun parts. If something is automated, it means that it happens uniformly and with the least amount of time wasted doing boring (and typo-prone) stuff such as building jars and transferring files.

Standardize

I am not writing about integration environments, but some of the same principles apply to build-and-development environments. Martin Fowler also has written a lot on continuous integration and how it is important to development—not just to change management and delivery. If every developer on a team runs the same build and test scripts before checking-in code, that means that there is no excuse for errors when it comes time to package code for release to quality-testing or customers.

Every company with which I have worked has its own set of coding standards and best practices. But each set helps with the build-and-development environments. If each team member can refer to a common set of best practices when they are creating code, this helps reduce errors. It also makes your code base look more professional. When you have thousands of classes, it helps new employees and external groups when you have common documentation, tabulation, and naming conventions. As an architect who is maintaining and designing a system, you should not have to try to figure out 10 different code conventions for 10 different members. A team should develop a best-practices document collaboratively, and then enforce the standards with plug-ins such as Checkstyle to make sure that developers do not forget.

I read a post on the Atlanta Java Users Group listserv about a company that had a dunce cap that had to be worn when a coder's commit did not meet the automated coding-convention checks that were part of the daily build. A dunce cap or slacker's corner might be a little extreme, but a reminder will ensure that few developers make the same basic mistake frequently.

Testing Diversity

The last key to a good build-and-development environment process is diversity. I do not mean lots of cultures, races, and nationalities on your team (although that helps, too); I am talking about diversity of build and test systems. If your software is supposed to run on Windows NT, Windows 98, 2000, Windows Me, Windows XP, Vista, Solaris, HP-UX, AIX, z/OS and Linux, it is important that your various development and test servers are a mix of these environments. If all or your developers run Windows XP, you might end up spending a lot of time during the late-cycle debugging z/OS bugs. So, mix it up; have some developers work a bit on each OS.

If this is impractical, just make sure that some of your development-integration environments run each operating system. This builds on the first rule of builds—run early, run often—and adds on the build for each system combination. This applies also to other components. If you run MySQL and Microsoft SQL Server, build and deploy to both. If you run JBoss, WebLogic, and WebSphere, you must ensure that you build and deploy frequently to all different application servers. This also shows how important automation is. Building and deploying to another environment should be as simple as a few more lines in your automation scripts.

Conclusion

Your build-and-development environment process should incorporate all four areas: build frequently, automate build and environment setup, common coding standards, and diversity of builds. If you create and implement a good process, it's like a time machine: You get free time to spend on more features (or more games of Halo in the common room). If you do not get this process right, you can get used to the fun task of hiring build engineers, because you will have a lot of developers quitting. Oh, yeah, and late nights debugging other people's code, because the release has to go out tomorrow. You will be doing that, too.

Critical-Thinking Questions

· What mundane tasks can be automated in my project?

· What tools can I use to automate?

· How can I develop a coding-standards and best-practices document?

· How should I structure my project?

Sources

· Claburn, Thomas. " Google Revealed: The IT Strategy that Makes It Work." InformationWeek, August 28, 2006. (Accessed January 7, 2007.)

Further Study

· Fowler, Martin. " Continuous Integration." Martin Fowler.com, May 1, 2006. (Accessed January 7, 2007.)

About the author

Brian Alexander Lee is a technology and management consultant, specializing in enterprise architecture and service-oriented architecture (SOA), and currently subcontracting for BearingPoint to the Centers for Disease Control and Prevention (CDC) in Atlanta, GA. He has been intimately involved in designing, developing, and implementing complex solutions for enterprise clients for over 10 years.

This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.