What is the Build Life Cycle?

While the application development life-cycle (ADL) process is broadly understood to encompass all aspects of software development, from requirements collection and management, modeling and design, development, testing and performance, to deployment, the specific aspects of the 'build to release' phase of the software development life cycle have not been described or broken down into discrete steps yet. As a result, there has been limited articulation regarding the key and growing role that the build process holds in today's component-driven development.

Generically, the software build process can be defined as the procedure for taking application source and generating application binaries for a software release. Software builds can be done in a periodic manner by the build team or build manager to provide baseline binaries which are used in ongoing development, testing, performance or even deployment work. The build process can range from compiling a stand-alone utility written in a single language to massively more complex scenarios. It is common to find a build process that checks code out of a version control system (VCS) or software configuration management (SCM) system, generates new code and content, performs unit and integration testing, assembles or patches code from other developers, and then compiles multiple components or sub-projects which are written in multiple languages for deployment to multiple platform targets, including a wide variety of hardware and software configurations.

While all builds basically share a generic definition, they have lacked a common, formal 'process' definition. This has been especially difficult for developers to automate since there is often little or no structure (pattern) to the work and tasks related to the software build itself.

Build teams and/or build managers must understand and track all of the applicable development tools, compilers, and source controls tools, for their software projects. In addition they must also fold into that project's build both the myriad of required life cycle activities (such as code check in/check out, compiling, unit testing, report generation, etc.), and the constantly-changing state of the code components themselves. Additionally, the components of a build often include more than just the project's code: often encompassing the names, versions, and directory paths of operating systems, specific libraries, linkers, or additional code on which the project itself depends. Worse yet, the majority of this dynamic build process knowledge is rarely institutionalized, documented or even effectively shared across teams or individual developers.

Consider the full scope of activities within the build life cycle. These are typically managed by batch files, Ant scripts, or small homegrown applications often written in scripting languages. In many cases, the build itself becomes a project, requiring extensive manual work to maintain proper working versions of the software project that the build itself is enabling. But, unlike software projects, builds don't share a common logic and generally are not object-oriented in their design. It is common to find two or more build implementations used for any given project within the same company. So while the activities across builds are consistent (process sources, compile, test, package, and deploy), the build process itself has not been.

Why Orchestrate the Build Life Cycle?

Since most build life cycles have not been encapsulated by any standardized processes or patterns, builds within many projects have become more art than science in enterprise development organizations. Many lack any underlying framework to support or enable the automation of the build process, because of the largely free-form, script-centric approach by which they are managed today. Exist Maestro builds on lessons learned from countless open source projects to enable an organization to identify and use a series of discrete, identifiable, repeatable steps that deliver an expected outcome to remove the guesswork from the build process.

Build management has been undervalued and under-served within most organization's ADL tool set. Given today's increasingly distributed, complex and highly-interdependent development paradigms, a comprehensive build management process is the linchpin of an enterprise's ability to successfully deliver software. Having a build process that consistently and reproducibly builds software is a critical requirement. A comprehensive build management process allows individual developers to spend more time on fulfilling functional requirements in their coding and testing efforts – rather than laboring on tedious code assembly activities or setting up testing environments and integration tests. Developers can do their job while, at the same time, the build system can ensure that any number of recognized build 'best practices' are being followed without requiring developer interaction. These best practices can include continuous integration (that is, daily or nightly builds), required code coverage, project reporting, and build reproducibility – all reachable without adding any complexity or overhead to the existing requirements of developers, build managers, build teams or project managers. In fact by using the built-in reporting mechanisms, project managers can gain valuable insight into the software development life cycle itself, while developers can gain instant feedback on various code metrics or test results by checking the continuous integration system.

What Exist Maestro provides is an open source platform that enables comprehensive build management based on Apache Maven's declarative, meta-data driven POM (Project Object Model) engine. Maestro integrates Maven's well defined, life-cycle phases, standardized directory layout and extensible plugin framework with Apache Continuum to deliver end-to-end build automation, test execution, project reporting and even site generation. Maestro also includes support for a centralized, hosted repository to enable higher developer productivity and better overall team collaboration and project coordination. Exist's distribution provides the following benefits to users:

Improved code reliability:

Ensure quality throughout the development cycle, not just at the release deadline, but with continuous project testing and integration that provide site reports, as well as automated notifications for errors or other compliancy-violations (such as, unsupported versions or license types) as they happen.

Accelerated release timelines:

Shorten lengthy, error-prone and highly, manual script-based tasks that can take hours or as much as days to complete, and require one-off, duplicated updates throughout the build file(s) for any environmental changes or additions to the project environment.

Increased project visibility:

Get real-time transparency into not only what code goes into a project, but who contributes what code, how often they contribute code, the test coverage for the code contributed, what happens to the build overall when new code is introduced (like does it break), and ultimately, what do all of the code contributions show about the status of the project.

Optimized code re-use:

Centralize, identify and manage not only all of your internal code assets, but also assets from offshore/outsourced development teams, and open source projects, but more than simply track code, understand the complete taxonomy of your code assets, from dependencies to authorship, versioning, and specifications

Advantages of Exist Maestro

The first open source build life-cycle platform solution

• Lower cost, for both initial adoption and expansion over time.
• Access to all Apache License 2.0 source code, and freedom to modify code as required.
• Access to an active development community, with no lock-in to any specific vendor.

Exist-Certified distribution

• Code versions are validated for quality and interoperability.
• No hidden license issues - All components are released under the Apache 2.0 License unless specifically identified as an exception.
• "Whole product" support: Exist provides documentation, demonstration examples, support for the entire platform.

Production subscription support and consulting services from Exist

• Innovative subscription model for support through the Community-oriented, Real-time Engineering (CoRE) Network, which offers subscribers the advantages of close collaboration, knowledge transfer and software indemnification.
• Enterprise-class support subscriptions based on industry-standard service-level agreements.
• Iterative and rapid issue tracking and resolution directly from members of the developer community.

Structure of Maestro

Maestro Developer Client

The Maestro Developer client includes Apache Maven 2.0.9, with a set of pre-validated life-cycle plugins, and configuration settings with access to the Exist Public Repository for stand-alone use by individual developers, as well as optional settings to integrate with the Maestro Project Server.

Maestro Project Server

The Maestro Project Server includes Apache Continuum, the Equinox sample project, the Jetty sample project, shared repository for access by Maestro Developer clients, project sites and access to the Exist Public Repository for team use by any number of developers.

Maestro Public Repository

Exist-hosted repository with a library of over 17,000 artifacts (jars, wars, ears), and a growing number of related resources including related sources and Java Docs, available at Exist Repository.