|
Governance in the Application Development Life Cycle: Build Management |
|
|
|
|
Research Spotlight -
Research Notes
|
|
Written by Ron Exler
|
|
Sunday, 15 April 2007 |
RFG believes build management, the process of transforming raw code into
executable applications, is growing in importance in enterprises' application
development life cycles. Managing application builds and deployment, once a
background task seeing relatively scant interest, is rising to the top of the
minds of development managers. This is because of a confluence of compliance
and governance, and a realization of the direct links to application quality
outcomes. IT executives should closely examine processes and tools in use to be
sure they are adequate for current complex requirements and deployment
environments.
Business Imperatives:
- Build management is emerging
from the background. Managing builds has, since the beginning of application
development, taken a back seat to other elements of the development life cycle.
Oftentimes it was considered an administrative task and a rather messy
necessity. Now, however, with the need for proper audit trails, cost reduction
pressures, security issues, quality concerns, and complex deployment scenarios,
build management is becoming one of the last frontiers for significant
improvement. IT executives should examine their build management processes and
solutions they are gaining in importance, and will soon match the levels of version
control and defect tracking.
- Finding
and fixing the causes of build errors is much less costly early in the
development process. Also, schedule demands have led to extreme pressure to
accelerate the application development life cycle, while quality thresholds
have risen. Because many errors remain hidden until software is built, the
general practice has evolved over the years from periodic builds, to weekly
builds, to nightly builds. Some projects build continuously, every time a code
change is checked into version control. With distributed development, including
outsourcing, as well as agile development, builds can be needed at any time in
separate locations. IT executives should examine build frequency, and ensure
proper process and tool use to match the complexity of their application
deployment scenarios.
- Quality
should the top priority in software development, but studies and results of
projects often show that it is not. The ability to integrate quality checks
into the early parts of the development life cycle can have tremendous positive
effects, as can proper processes. The related tasks of managing release builds
in today's complex service-oriented architecture (SOA) and multiple-platform
deployment environments require automation and continuous human oversight to
attain the highest quality, lowest risk outcomes with proper audit trails. IT
executives should determine if sufficient expertise exists in house for build
management, whether critical build/release knowledge is only understood by
limited resources, and whether tools in use are adequate and can meet the long
term needs of the enterprise. Then, if, appropriate, they should seek external
assistance.
The potential for bad things to happen to
good projects is drives what build management. Companies are concerned with
adhering to the best practices, quality initiatives, and many regulations
necessary for running their businesses. For those developing applications, the
ripple effect of this scrutiny means they must improve how well they can audit
and secure their applications. To do so requires proper granularity of
traceability. Build management can provide such insurance.
When build management is not done correctly,
it leads to big problems. The release process can be a troublesome bottleneck.
Using ad hoc scripts, developers might assemble code with old or broken
components. Or the dependencies between application components could be missed.
In addition, improper build management errors can easily find their way into
deployed applications. Oftentimes builds simply take too long to complete,
delaying important application releases. Furthermore, fixing these problems can
be a laborious and time consuming process.
Strategies for improving build management
involve not only addressing the scripts but providing needed horsepower to the
build process. In many enterprises, large builds now run on dedicated servers
or across a series of connected server grids. However, it is a mistake to
blindly apply more horsepower to improve build performance without
investigating the underlying causes of issues.
Builds are considered too slow for a variety
of reasons. In many cases, the applications are large and growing, leading to
longer compile times. In addition, some of the build tools build and compile
everything regardless of changes, such that a few changes in a large
application can still result in a slow build. An approach used in some
commercial tools is to scan for dependencies, thus reducing the builds to be
incremental, saving time and resources. IT executives facing unacceptable build
performance should first determine underlying reasons for the issue and then apply
a strategy that addresses those findings.
Ideally, build management is invisible. The
trick is to come up with a robust end-to-end process for the specific
organization. For example, by automatically generating a build whenever a
developer checks in changed code, errors are caught at that point. This concept
of continuous integration is now touted by many as a key component to a
successful modern build methodology. In addition, enterprises can achieve
further quality by automating the test process as well when a build executes
successfully.
Build Management Processes and People
No process works without the cooperation of
the people involved. Some developers view process in general and build
management specifically as unhelpful. There is a strong and large subculture in
development that posits that anything that gets in their way, slows them down,
or adds unnecessary burden is an inhibitor to progress. IT executives needing
to promote build management must show how it improves not only project outcomes
but individual developer performance.
Agile development also changes build
management. Awareness of the importance of proper builds increases with the
need to deliver on every cycle of development. The acknowledgement, however, is
tempered by the attitude amongst some that they can pick and choose what to do,
rather than following a traditional methodology.
In some shops the concept of continuous build
and test is catching on. The concept is that whenever a developer checks in
code, there is an automatic build and/or test to determine whether those
specific changes cause problems. This is in contrast to the traditional process
in which changes are grouped into a build at a predetermined time. In the
latter case, the build might have hundreds of changes from several developers
over many days. After the build completes in a satisfactory manner, then
testing occurs. This traditional process can hide errors until later in the
process, at which time the root causes take longer to track down and are more
expensive to fix. Most of the tools vendors now offer continuous integration.
Build Management Tools
There are many options for tools, but they
differ. There are two major functions of build management solutions. One is
creating and optimizing the scripts used to build applications, which can be
termed build services. This involves determining dependencies between code
packages, pulling the pieces together, and compiling executables. Improving
performance of builds can result from splitting builds between computers,
building in parallel. Another method commonly used is building incrementally
rather than completely at the end before testing and deployment.
Process automation involves ensuring proper
workflow, managing and controlling builds. These capabilities eliminate or at
least reduce manual, error-prone handoffs. They collect and retain information
from each stage, enabling the ability to repeat builds and provide management
reports on key development metrics and trends. Security enforcement is also
generally woven into build process automation.
Some tools provide process automation while
others concentrate on build script optimization. A few of the vendors offer
both. However, the greatest measurable gains using commercial tools over manual
methods or open source comes from faster builds. It is easy to determine the
speed of builds but more difficult (though not impossible) to show benefits of
process improvements. IT executives should focus on both parts of the build
management challenge - build process and build services - to ensure optimal
outcomes.
There are several commercial alternatives for
build management, including:
- Alcatel-Lucent nmake Product Builder
- Borland Software Corp. Gauntlet
- Codefast Inc. PerfectBuild
- Electric Cloud, Inc. ElectricAccelerator, ElectricCommander
- IBM Corp. Rational
Build Forge
- Kinook Software Inc. Visual Build Professional
- Microsoft Corp. nmake (not related to Alcatel-Lucent nmake Product Builder)
- OpenMake Software (formerly Catalyst Systems Corp.) Openmake
- Telelogic ABSynergy
- Urbancode Inc. Anthill Pro
- Vsoft Technologies Pty. Ltd. FinalBuilder
- Xoreax Software Ltd. IncrediBuild
Integrated development environments (IDEs)
are moving some of the administration tasks into the background. For build and
release management, the IDEs are more regularly handling these functions
internally. However, the IDEs generally lack the necessary capability to
address all development needs, especially when crossing platforms or scaling to
enterprise builds.
Over the past year, much has occurred amongst
vendors of commercial build management solutions:
- Feb. 2006: Borland
acquires Gauntlet Systems
- Mar. 2006: Catalyst
Systems releases Openmake 6.41 with life cycle activity process scheduling and
accelerated build performance
- Mar. 2006: VSoft
releases FinalBuilder 4.1 with integration to Microsoft VirtualServer and
others
- May 2006: IBM Acquires
Build Forge
- May 2006: Codefast releases
PerfectBuild 2006
- July 2006: Xoreax
Software releases IncrediBuild 2.61 with build groups, graphs, and improved
performance
- July 2006:
Alcatel-Lucent nmake Product Builder lu3.8 released with new platform support,
enhanced build tool support, and improved performance.
- Oct. 2006: Vsoft
releases FinalBuilder 5 with graphical views and reports
- Dec. 2006: Electric
Cloud introduces ElectricCommander for automating build management processes
Governance in the Application Development Life Cycle: Build...
Tuesday, March 20, 2007
- Dec. 2006: The Apache Software Foundation Ant 1.7 release introduces the ability to
group resources, supports Java 6, and fixes many bugs
- Jan. 2007: ElectricCloud
receives Series C financing
- Feb. 2007: Catalyst
Systems Corp. changes name to OpenMake Software and hires new CEO
- Feb. 2007 Borland
introduced Gauntlet, a build and test automation tool that highlights potential
quality problems by automatically testing and analyzing changes through
existing version control processes, including those running in Borland
StarTeam, as well as open source tools CVS and Subversion.
- Mar. 2007: OpenMake
Software releases Mojo, a free process automation solution, based on and
integrated with the The Eclipse
Foundation framework
- Mar. 2007: Urbancode
releases AntHill Pro 3.2 with improved integration, management, and security
- Mar. 2007: Xoreax
Software releases IncrediBuild v3.00 (Public Beta) with a new grid engine and
other enhancements
- Mar. 2007: Codefast
releases PerfectBuild 2007 with a new graphical interface as well as additional
platform and language support
Well-funded build management startups are
making noise and progress, and the sector is gaining increased attention.
Codefast recently received an investment of $3 million ($9.5 million to date)
and Electric Cloud recently landed $9 million ($22.1 million to date). OpenMake
Software is also ramping up its efforts. In addition, Borland and IBM acquired
small vendors, Gauntlet Systems and Build Forge, respectively. The result is
much more marketing which further raises the awareness of build management and
also raises the relative visibility of these providers.
Open Source Tools
A rising tide raises all boats, and therefore
open source build solutions are growing in popularity. There are many open
source build tools; it seems many developers think they can build a better
mousetrap. However, many of them are rarely used and updated only sporadically.
Only a few are widely deployed and respected. Many development teams start and
finish with open source for program builds. Almost everyone starts with Make
and Ant and few go beyond them, especially for smaller projects in small
companies. However, these tools do not scale, the reporting is often poor, and
user interfaces are weak.
While open source build solutions might be
adequate for many applications, they have limitations the commercial solutions
address. In addition, those using open source are generally at the mercy of the
community, which is variable in its responsiveness and applicability. In light
of all that, it is certainly better to use open source to get started and prove
the value of build management. IT executives in enterprises that do not
understand the value of build management should immediately move to show
benefits using a pilot project with either a vendor's assistance or using open
source tools.
There are several widely used open
source application build systems, including:
The choices for enterprises in this area come
down to the open source toolkits like Ant that offer basic do-it-yourself
capabilities and the commercial solutions. Many of the commercial vendors will
support open source tools, and add value through best practices, packaging,
specialized technologies, templates, and services. IT executives should
consider both commercial and open source development solutions, perhaps
combining them in some cases to meet enterprise development needs.
The tool decision comes down to a few
interrelated decisions:
- Do you use open source,
commercial, or mixed tools?
- Do you keep existing
scripts or migrate to new build services?
- Do you layer in process
automation and reporting?
The right answer for a particular enterprise
depends on:
- Application magnitude -
the largest applications often need the performance and scalability of
commercial tools, while open source can suffice for smaller ones.
- Audit, compliance, and
management requirements - the tools vary in their reporting and tracing
capabilities.
- Build scripts - if the
existing scripts are complex and problematic, it would not make sense to
automate processes around them without improving the scripts?
- Development methodology
- traditional methodologies would drive a different solution than agile
approaches.
- Development team
expertise, size, and distribution - here also, the commercial solutions tend to
be more robust in their support of large, distributed teams.
- Deployment environment -
deploying to one platform is much different from deploying to several. Also,
the number of customized versions of the software comes into play.
- Existing and planned
development environment - integration with IDEs is essential for maximum
effectiveness of build solutions.
Success Built on Expertise
In the end, build expertise is more important
than the tool. The nature of the build challenge is that there are many
available viable tools, and the issue is how to create and manage a repeatable
and scalable build process. For many enterprises, this requires experts who are
either with the commercial providers or are independent consultants. RFG
discussions with those who use commercial and open source solutions point to
expertise as the key to success. Those knowledgeable about the build process
and tools can ease implementation and provide invaluable guidance in a
transformation from manual or suboptimal methods.
External resources include independent
consultants as well as tools vendors. In the build management space, most of
the vendors offer excellent resources, especially those vendors with many years
of experience. Independent consultants generally know more about open source
alternatives. IT executives should gather consultation first (internal or
external), followed by pilots on real systems, to fare the best in the long run
in build management.
RFG believes enterprises and independent software vendors
must pay close attention to how they build applications. For many, deployment
is a big, scary predicament. It is no longer acceptable to leave the process in
the hands of untrained people, weak processes, and shaky tools. What is needed
is integration of builds into the application life cycle with proper training,
external expertise where needed, solid repeatable processes, and
enterprise-class tools. IT executives seeking to reduce risk and improve
application quality should dig into their build management situation and make
changes if and where necessary.
RFG analyst Ron Exler wrote this
Research Note. Interested readers should contact RFG Client Services to arrange
further discussion or an interview with Mr. Exler.
Copyright © 2007 Robert
Frances Group, Inc. All rights reserved. Agenda products are published by
Robert Frances Group, Inc., 120
Post Road West, Suite 201, Westport,
CT 06880.
Telephone (203) 429-8950. Facsimile (203) 429-8930. http://www.rfgonline.com. This publication and all Agenda
publications may not be reproduced in any form or by any electronic or
mechanical means without prior written permission. The information and
materials presented herein represent to the best of our knowledge true and accurate
information as of date of publication. It nevertheless is being provided on an
"as is" basis. Reprints are available.
Trackback(0)
 |
|
Last Updated ( Friday, 01 August 2008 )
|
|
WHITE PAPERS -- Become a Member and Login and you will never fill out forms again!
Check out the TOOL SPOTLIGHT!
|
TrackBack URI for this entry
Subscribe to this comment's feed
