Home 
CM Journal Articles Using a Commercial Tool to Automate a Build and Deployment Process
CM Journal Articles Using a Commercial Tool to Automate a Build and Deployment Process
|
 Your responsibility is to "design and build tools to run and monitor an optimized, parallel, nightly and on-demand build and deploy system across multiple development branches in multiple environments." How will you tackle this challenge? Will you create tools from scratch or will you construct a comprehensive system by customizing an existing framework?
This assignment is real. It appeared in the job description for a Senior Configuration Management Engineer on a company's web site. An abbreviated description of this position appeared in a recent job posting on CM Crossroads. By scanning the job postings on CM Crossroads, and by reading the discussion forums on this site, you can see that comprehensive build and deployment automation is a hot topic. Complex build and deployment procedures, coupled with the need to deliver quality software faster, make build and deployment automation a top priority for software development organizations. Often, some build and deployment automation exists. Usually, it is not the comprehensive automation that reduces the build and deployment process to the click of a button or the firing of a trigger. While not a silver bullet, build and deployment tools provide a solid foundation for constructing the automated system envisioned by a growing number of software development organizations. Read the sections that follow to understand how to use a commercial tool to automate your build and deployment process. Definition of a Build and Deployment Tool For the purpose of this article, a build and deployment tool is a framework that can be configured to automate the build and deployment process for one or more software applications. Typically, this process begins with building a software application and ends with deploying the application to test and production environments. This process may include some, or all, of the following steps.
Comparison with Continuous Integration (CI) Servers A build and deployment tool is not exactly the same as a Continuous Integration (CI) server. While both tools create builds, the builds created by each tool serve different purposes. A build and deployment tool creates a candidate production build using the files from a label, tag, or snapshot in a codeline maintained by the version control tool. Each build is started by the firing of a trigger, or by the click a button on a GUI. After creating a candidate production build, the build and deployment tool can deploy the build to a test or production environment. The build and deployment tool can service multiple build and deployment requests simultaneously. The requests can be for one or more software applications. A CI server creates a throw-away build from the most recent version of each file in a codeline in the version control tool. Each build is started after changes are detected in the codeline. The CI server executes the same build script that is used to produce a production build. Most likely, the build script executes a suite of unit tests. Additionally, the build script, or a separate script run by the CI server, deploys the build to a test environment. The build, unit tests, and deployment are executed as part of one build cycle triggered by the CI tool. The CI server may run multiple CI builds simultaneously. The builds can be for one or more software applications. Other than the type of build created, the functions of a build and deployment tool are similar to those of a CI server. A critical difference between a build and deployment tool and a CI server is the architecture of each tool. Typically, a CI server is designed to create each CI build on the same physical server. In contrast, a build and deployment tool is architected to distribute the work of building and deploying across several physical servers. Architecture of a Build and Deployment Tool Tools that automate the end-to-end build and deployment process often need to execute commands on several physical servers. After building the application on a designated build server, the application needs to be deployed to one or more servers in a test environment. For example, the components of a J2EE application may need to be deployed to application, web, and database servers in one or more test environments. Most likely, the application, web, and database servers reside on separate physical servers. Build and deployment tools that e mploy a server-agent architecture distribute work across multiple physical servers. The server is the software component that processes requests for builds and deployments. The agent is the software component that runs the scripts and command line instructions from the command line on a remote server. The scripts and command line instructions executed by the agent satisfy the build or deployment request from the server. Together, the server and agents act as a centralized job controller with distributed job execution engines. Agents can be installed on a group of build servers to create a build farm. The server component of the build and deployment tool receives requests for builds then assigns each request to an agent that is able to service the request. Depending on the build and deployment tool, each agent can run one or more builds on the same physical server. Even if an agent is limited to running one build at a time, agents distributed across multiple build servers allow the build and deployment tool to run multiple builds simultaneously. While builds can be executed on any server that is configured to build the application, deployments must be executed on the server(s) where the application will run. Deploying a distributed software application can be involved because different build artifacts need to be deployed, in the proper sequence, to different physical servers. For example, database changes may need to be made to a database server before build artifacts can be deployed to web and application servers. Often, different accounts, or user IDs, run the different components of a distributed application. When deploying a distributed application, such as a J2EE application, the appropriate account must be used to execute the deployment script on the right server. Typically, the agent that deploys a build artifact runs from the account that must execute the deployment script. For example, the agent that executes the database deployment script runs from the database account on the database server, the agent that executes the application server deployment script runs from the application server account on the application server, and the agent that executes the web server deployment script runs from the web server account on the web server. Using a Build and Deployment Tool By understanding the architecture and function of a build and deployment tool, you can develop an approach to automate your build and deployment process. The sections that follow serve as a how-to guide for using a commercial tool to automate your build and deployment process. Evaluate Candidate Tools Automating your build and deployment process starts with assessing candidate tools. The evaluation is manageable if you accept the argument that a server-agent architecture is a requirement for an enterprise build and deployment tool. AnthillPro, Build Forge, and ElectricCommander are established commercial build and deployment tools that employ a server-agent architecture. Cruise is a new commercial tool from an established consultancy. Like the other commercial tools, Cruise also uses a server-agent architecture. For an explanation of why you should consider AnthillPro, Build Forge, Cruise, or ElectricCommander, read How I Came to Value Commercial Build and Deployment Tools. For more information about these tools, review recent webcasts and the tool spotlight on CM Crossroads. Even if you are sold on the benefits of using a build and deployment tool, finding the right tool requires time and effort. The only way to find the right tool is to install and configure candidate tools in your development environment. Your objective should be to configure each tool to automate a relatively straightforward build and deployment. In addition to providing you with evaluation software, tool vendors will provide you with support when installing and configuring the software. Plan to spend several days working with each tool. Start with the product documentation. Look for a quick start scenario that will immerse you in the automation of your build and deployment. Strive to implement a simple scenario in a day or two. Once you have implemented a simple scenario, contact the vendor to learn how to use the tool's features to improve the implementation. The vendor will be able to introduce you to capabilities of the tool that will make your implementation more robust and extensible. Define the Build and Deployment Process Defining your build and deployment process is a prerequisite for automating that process. This is true even for the simple process used for a tool evaluation. The best definition of your build and deployment process is a list of every activity that takes place from the start of the build to the end of the deployment. Describe each activity in detail. Ideally, each step in the list should identify who executes what commands on which servers. Start with the instructions you execute to obtain the files from the version control tool. Include the command(s) to create a label, tag, or snapshot of the files to include in the build. Next, record the instruction(s) to update a workspace on the build server with the files in the label, tag, or snapshot. List the command(s) to identify the changes included in the build. You may identify changes based on files or change packages from the version control tool. Alternatively, you may identify changes as fixed issues from the issue tracking system. Next, identify the command(s) you execute to build and unit test the application in the workspace on a build server. Include the command(s) to perform static code analysis on the files in the workspace. Of course, this assumes that you can build, unit test, and analyze code by running a build tool (like Ant, Maven, or Make) from the command line. If you rely on an Integrated Development Environment (IDE) exclusively for your builds, develop a build script that runs from the command line. While an IDE is an ideal tool for developers, it is not an appropriate tool to use to create candidate production builds. After listing the build command(s), identify the step(s) to copy the build artifacts to the test servers. If your build produces more than one artifact, determine the target server(s) for each artifact. Next, list the command(s) you execute to deploy the build artifacts on the test server(s). If your deployment is involved, develop one of more scripts to automate the deployment steps. Finish the list with the command(s) you execute to run any automated tests following the deployment. Consider scripting these tests if the setup and execution is involved. Define the Build and Deployment Environment Listing the commands and scripts that you execute is only part of the process. The commands and scripts that you execute only work with the proper parameters and environment configuration settings. Determining the appropriate parameter values and environment configuration settings can be as involved as creating some of the scripts that support the build and deployment. To define the parameter values, return to the list that defines your build and deployment process. For each command that you listed, identify all arguments that are passed to the command. Determine the value of each argument. Identify how the value of each argument is obtained. To define the build and deployment environment, return to the list that defines your build and deployment process. For each command that you listed, identify the user ID that executes the command. Identify the server where the command is executed. Additionally, list the value of every environment variable that must be set before the command is executed. Identify how the value of each environment variable is set. Configuring the Build and Deployment Tool Tools that automate a build and deployment process are designed to execute the steps that comprise that process. The tools are also designed to configure the environment required to execute these steps. Typically, build and deployment tools use a project as the top-level container for build and deployment automation. A project in the tool corresponds to the development branch of a software application. Depending on the tool, the project is, or contains, the unit of automation. When the project is not the unit of automation, the automation may be implemented by a workflow or job. Whatever the unit of automation, it contains the steps to execute. These steps correspond to the steps that you listed to define your build and deployment process. Configuring a tool can be as easy as entering each command from the list that defines your build and deployment process. Along with each command, you specify the arguments and environment configuration settings. Since the build and deployment takes place on different servers, the unit of automation is tied to an agent that executes on a server. For example, the project, job, or workflow that contains the build steps is run by an agent on the build server. The project, job, or workflow that contains the deployment steps is run by an agent on the deployment server. To define each unit of automation, group the steps in your build and deployment process according to the server where the steps execute. The steps that execute on one server comprise a unit of automation. This unit of automation is run by an agent on a physical server. Running Builds and Deployments Build and deployment tools support both scheduled and on-demand builds and deployments. Once the build and deployment process is defined and modeled by the tool, the process can be run by the automatic firing of a trigger, or by the press of a button on the GUI. Scheduled activities are likely to include daily builds and deployments to test environments. On-demand builds are likely to be run when the latest code change needs to be integrated in preparation for testing. No matter how a build or deployment is initiated, the output from each command is logged so that it can be viewed from the tool's GUI. If the build or deployment fails, the tool's GUI displays the steps executed up to and including the failed step. If you specify your build and deployment process at a fine level of granularity, the build and deployment tool will make it easy to identify and troubleshoot the cause of a failure. You do not need to monitor the tool's GUI to determine the status of a build or deployment. Build and deployment tools will notify you by email or IM when a request completes or fails. Additionally, the tools track and report the status of each request. This allows you to identify trends over time. Maintaining an Automated Build and Deployment Process Your build and deployment environment is not static. It evolves to support changes to your software application. This is a natural and expected part of software development. However, changes to your environment can wreak havoc on brittle build and deployment automation. Fortunately, the commercial build and deployment tools that employ a server-agent architecture are not brittle. They are frameworks that are flexible enough to allow you to make changes quickly and carefully. What type of changes can you expect? You might need to use a new compiler for future software releases while keeping the existing compiler to support the current release. The framework provided by a build and deployment tool makes this type of change easy to implement. Environment configuration settings allow you to switch from one compiler to another, or to use different compilers for different builds. Refactoring your implementation should be part of maintaining an automated build and deployment process. Not by accident, the frameworks provided by the commercial tools make refactoring painless. Whenever possible, attempt to generalize the automation. For example, you might be able to replace several deployment jobs with a single job that can be used to deploy different applications. As you become familiar with the build and deployment tool, you will identify features that will support the refactoring of your process automation. Additionally, the tool vendor and the community of tool users can offer recommendations for how to generalize your automation. Summary and Conclusion It is possible to implement an optimized, parallel, nightly and on-demand build and deploy system across multiple development branches in multiple environments. Rather than architecting and building this system from scratch, you will save considerable time and effort by using a commercial tool to automate your build and deployment process. Commercial tools that employ a server-agent architecture are ideally suited for automating a complex build and deployment process that involves multiple servers. Begin your process automation by documenting your build and deployment process, and by evaluating candidate tools. Develop a list of the steps you execute to build and deploy your application(s). Translate this list into units of automation that can be executed by a commercial tool. After automating your process, strive to continuously refine it to make the units of automation more general. Work with the tool vendor and other tool users to learn how to make the most of your investment in a commercial build and deployment tool. Michael Sayko is a software configuration management consultant based in Austin, Texas. From serving as a build and release engineer on several projects, he is experienced with Continuous Integration and build and deployment automation of J2EE applications. You can reach Michael by email at mss@acm.org.
Set as favorite
Bookmark
Email this
Hits: 7027 Trackback(0)Comments (4)
|
TrackBack URI for this entry
Subscribe to this comment's feed |
... Austin, Thanks for the feedback. I am pleased that you found the article to be helpful. |
Austin Hastings
said:
 |
... What an excellent article! Thank you Michael for writing a clear introduction to the concept. I'll be referring people to this article for quite a while, I think. Bravo! =Austin |
Michael Sayko
said:
|
... There are a variety of tools that can be used to implement a Continuous Integration (CI) server. Open source CruiseControl is a popular tool that is ideally suited for CI. Tools that implement CI can also be used to create production candidate builds. However, CI tools are not exactly the same as build and deployment tools. Build and deployment tools that employ a server-agent architecture are especially well suited for deploying complex, distributed applications. Together, the server and agents act as a scheduler with remote execute engines. When deploying a distributed application, such as a J2EE application, the agents on different physical servers deploy different application components. Each agent runs as the appropriate user on a physical server to execute the deployment script that runs on that server. AnthillPro, Build Forge, Cruise, and ElectricCommander are build and deployment tools that employ a server-agent architecture. These tools can be used to create both CI builds and production candidate builds. One of the unique strengths of these tools is their ability to deploy distributed applications by executing the appropriate deployment script on each remote server. Without agents on remote servers, a distributed application could be deployed by using SSH key-based authentication with sudo to execute the appropriate commands, from the appropriate account, on each remote server. Unfortunately, this approach is not as robust as one that uses agents to execute the appropriate script, as the correct user, on the right server. I encourage anyone who is automating a build and deployment process to consider the available commercial and open source tools. However, I strongly believe that AnthillPro, Build Forge, Cruise, and ElectricCommander are the top contenders when considering a commercial tool to automate build and deployment processes for the multiple development branches of one or more software applications. |
Slava Imeshev
said:
 |
... Hi Michael, You might want to add our Parabuild http://www.viewiter.com/products/parabuild.htm to your list of commercial build tools. Parabuild is an established system used by hundreds of organizations and came to exist long before most of the other commercial tools. Regards, Slava Imeshev |
Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.
