Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

DDJ: Joining us today is Nick Berens, CEO of Codefast, a company that specializes in build automation and management tools.

Nick, in the July issue of Dr. Dobb's Journal, we asked the questions "What's the Buzz About Builds?" What's your take on it? Why is there so much interest and activity in this type of tool right now?

NB: I think there are a number of factors driving "the buzz". Organizations are starting to realize that there is a positive correlation between build frequency and delivering high quality software on schedule. We see a lot of organizations trying to increase frequency. Companies that are building weekly are trying to build daily, companies building daily are trying to do it multiple times a day. Continuous Integration is the end point of this line of thought, where you are building at every check in. Increasing build frequency can put a lot of new demands on the existing build system in terms of speed, reliability, and usability.

Another driver is the increase in product componentizing initiatives. These efforts are usually driven by the businesses need to become more responsive to customers and market opportunities. Right now SOA is probably the most well-known example of this but its by no means the only one. Organizations are trying to get to a point where they can deliver a number of separately managed components that can be assembled in various ways, rather than releasing a single monolithic piece of software. These sorts of efforts require a different kind of build system. From the build perspective, you want a system that knows how to work with components, like our PerfectBuild.

ALM is also creating demand for improved visibility into and control of the software process and this impacts the build system as well. Users want more data from their build systems, they need to be able to reproduce results on demand and provide audit trails if there are problems.

And then finally there are basic cost factors. Most build systems are developed and maintained in-house. Just like any other in-house developed application, they can require a great deal of time and expertise -- time and expertise that could be used elsewhere in the business. Additionally many organizations will have multiple build systems each with its own team of experts so the costs can become pretty significant. From this perspective, organizations are faced with a "build vs. buy" situation. The exciting thing is that build systems have improved to the point where the scales are starting to tip towards the "buy" end more often than not.

So when you take all these factors together, its easy to see where the buzz is coming from.

DDJ: Codefast, your company, focuses on "pattern-driven build automation". What does that mean?

NB: One of the characteristics of software builds is that they are pattern oriented. Most of the time you are doing the same thing over and over -- building a DLL or a WAR or running an installer to package up your artifacts. Certain attributes of the pattern may change depending on the project, what machine you are running on or what operating system you are using. But no one would deny that there is a basic pattern operating in any build effort. Patterns are occurring at various levels of the build process. You can look at an entire build system as essentially a set of patterns within patterns.

This fact is behind what we call "pattern-driven automation," which is our approach to process automation. We store patterns in our system and then apply them depending on the context they are used in. So for example say you are building a set of files on Windows and you want to build them on Linux. We automatically apply the Linux context to that basic pattern. We adjust the platform specific attributes, compiler setting, file locations, any aspect of the process can be modified. And we don't just support platform contexts. You can create contexts for anything -- sites, projects could all have their own contexts that can be applied to a basic pattern.

We also separate file dependencies from the pattern itself. This lets us easily scale a pattern. We can distribute a build to a group of machines, execute a build in parallel or we can build incrementally -- all without the user having to do anything. This automation concept can be extended to any tool in the build-release chain making our approach suitable for automating the entire production lifecycle.

There are a couple of advantages to this approach. Probably the biggest one is in the area of improved flexibility.

One of the big problems we see with legacy build systems is that they can be very difficult to make changes to. This means as the organization evolves, the build system can begin to be a drag on growth. Some organizations get into situations where they are attempting to architect their code base around the build system because it's just too much work to change it. That just isn't right. From this perspective when you start considering the buzz drivers I mentioned, you can really see where demand is coming from. Implementing something like Continuous Integration may require a big rework of an existing build system and if your system is inflexible and hard to change you are going to have a big problem.

Using our pattern-driven automation approach you can create a system that is very flexible and easy to change even on a very large scale. System-wide changes that were unthinkable can happen very quickly with PerfectBuild. If you need to make a change to a process you simply call up the relevant pattern or context and make the change. Compare this with wading through a bunch of Make or Ant files trying to figure out how to implement a change -- its a huge time saver. The build system doesn't have to be the limiting factor in a process change.

Another problems users have is in the area of consistency. Development will be building things one way and production another. This means that when development checks something in you can't rely on it building in production. With pattern-drive automation both organizations can be working with the same basic set of patterns. Differences can be managed separately and applied automatically. This can be scaled up to an enterprise level. You can have teams all using the same basic sets of patterns. This let's you turn the whole software production effort into a factory-like process that can be managed by a small number of people.

DDJ: Once the build problem has been solved -- assuming that it is a problem and that it can be solved -- what is the next big challenge for software development?

NB: We think that the "build problem" masks a set of challenges in the software development cycle that will be more apparent as the fundamental build issues are overcome. These challenges center around agility: the ability of a software development team to "really" be agile -- from design to coding to testing and deployment -- a true beginning-to-end agile development cycle. The issues here are two fold: First is the integration and automation of the existing smaller agile cycles (Build, Test, and so on) into a method of development that crosses all these boundaries to achieve the goals of increased quality while decreasing the time to value/market for the application.

The need for automation technology that can easily act as an umbrella agile framework for all phases is an open area. This challenge is made even greater by the need to be able to adopt and use tooling, especially open source, in each of these areas (build, unit test, regression test, deployment) in a timely and cost effective fashion. Software development is an extremely dynamic business with significant innovations occurring all the time. Organizations want to be able to take advantage of these innovations without having to tear apart their infrastructure or create a lot of exceptions.

DDJ: Is there a web site that readers can go to for more information?

NB: Yes. Readers can visit www.codefast.com for additional information. There you can get a copy of our "little red book", Software Lifecycle Automation, which goes into details about our pattern-driven automation.

RELATED ARTICLES Distributed Software Development Explained Mathematical Models, Computational Techniques, and Music Telephone Call from Istanbul The Architect's Role Developer's Notebook		TOP 5 ARTICLES No Top Articles.