Agile SCM – Build Management for an Agile Team

[article]
Summary:
A number of people work together to develop a software application. The application is useful only when the components each person works on come together: the process of integration. The mechanics of integration happens during a build. Last month we discussed continuous integration. Integration implies building and this month we'll talk about the various kinds of builds one does during a development process.

Some Definitions

To make sure that we understand each other, let's start by defining some terms that we'll be using in the article. Hopefully the definitions are similar to the ones that you use; but if not, there should be a simple mapping from your terms to ours.

A build is the process step where you integrate all or part of your application. The build can include steps like retrieving the correct components from various locations in the repository, compilation, running scripts that generate source files from meta-data, etc. In short, anything necessary to go from a set of source files in your version management system to a component that provides value to someone. The product of a build can be a complete application or a component for distribution.

The inputs to a build are source components which include source files, meta-data files, and pre-compiled third-party library components.

Builds can be full (a.k.a. "clean") or incremental (a.k.a. "dirty"). An incremental build makes use of a dependency checking system so that you only build derived components from source components that have changed since the last build. A full build starts with no derived components.

Builds are often orchestrated by build scripts.  These can be Make files, ANT scripts, batch files, etc.

Building and Agility

Agile software development is based on a feedback loop between the developer and the customer. The development team implements functionality based on customer input, the customer evaluates the current state of the product against their list of requirements and the schedule constraints, and the team starts a new iteration to implement the next set of functionality.

This feedback cycle works best when the time between iterations is small. What small means depends on your team and process that you are using. XP teams typically use iterations of 2-3 weeks, Scrum teams use slightly longer cycles. Regardless of the customer iteration length, it is important to monitor the state of the process so that the system does not degrade unexpectedly. On the other hand, if you spend too much time on monitoring, you will have that much less time to do development of new features.

Important as it is, you should develop build (and deployment) processes early on in the project so that they evolve as the product evolves and so that they don't take up much time. The build is an infrastructure step that helps you to create a product. It is not an end in itself.

Agile software development depends upon a hierarchy of build practices that allow you to balance the need for speed and the need for stability.

Writing build scripts early does some of the same good things for your architecture as test-first development does.

Kinds of Builds

We've identified three patterns for builds: Private System Build, Integration Build, and Release Build. Each type of build has a different scope and frequency to resolve a slightly different set of concerns for its target consumer.

  • Private system build:  Used to build a system to use for testing in your private workspace. The consumer for this build is the developer doing ongoing work.
  • Integration build:  Integrates everyone's changes in a central place. The primary consumer for this build is the development team, both for the purpose of having additional assurance that the code integrates in a "clean" environment, as well as for integration level testing in advance of the release of the software.
  • Release build:  Packages the software for release. The consumers of a release build are the testing team (for pre-release) testing, and the customers of the development team (for production use).

Pages

About the author

Brad Appleton's picture Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the book Software Configuration Management Patterns, a columnist for the CMCrossroads and AgileConnection communities at Techwell.com,  and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.

About the author

Steve Berczuk's picture Steve Berczuk

Steve Berczuk is a Principal Engineer and Scrum Master at Fitbit. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at steve@berczuk.com or visit berczuk.com and follow his blog at blog.berczuk.com.

About the author

Steve Konieczka's picture Steve Konieczka

Steve Konieczka is President and Chief Operating Officer of SCM Labs, a leading Software Configuration Management solutions provider. An IT consultant for fourteen years, Steve understands the challenges IT organizations face in change management. He has helped shape companies’ methodologies for creating and implementing effective SCM solutions for local and national clients. Steve is a member of Young Entrepreneurs Organization and serves on the board of the Association for Configuration and Data Management (ACDM). He holds a Bachelor of Science in Computer Information Systems from Colorado State University. You can reach Steve at steve@scmlabs.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09