“Business value sooner” is a phase often spoken in—and to—IT development shops. It’s a simple phrase, but it has been pondered by the best IT project managers. Is the answer Scrum, pair programming, test-driven development, or something else? A solution is within the agile family.

Extreme Programming, a member of the agile family, has practices called continuous deployment and deployment automation. These processes support a system where builds and deployments are run constantly in an effort to smoke out problems immediately.

Deployment automation also provides business value sooner. This makes for a better return on investment. Many of the largest Internet companies use deployment automation as a practice. It not only gets features to market sooner but also gets defects resolved sooner.

What does it take to configure a deployment automation environment? A good place to start is with a developer integration environment. The integration environment is a computer or a cloud image where the development team delivers their change sets. Change sets are the code module files or documents either created new or modified during the recent development effort.

The most efficient process is to integrate the development teams’ change sets in an integration environment that is the team’s delivery focal point. The integration environment will also support integration testing to validate that all change sets can build. As integration builds are run, each successful build is a deployment candidate.

This deployment candidate is in the form of a deliverable file like an archive file, such as a .jar, .war, or an .exe file. They are the build result. When executed, these files will run the software product developed to satisfy the needs of the business.

The integration environment and the deployment candidate make up the first step in deployment automation. Proper deployment automation calls for a tool to execute the process. The tool can be either a commercial product or a solution developed in house. Either way, it needs to manage and facilitate some core components and steps.

The deliverable is one important component that must be managed. Any tool you are working with needs to be able to manage that deliverable by marking or labeling it. Without a label, you will have no good way to track the automated deployments.

The next two core components are the path of the target environment and the target environment. The target environment can be either physical or a cloud image, but it must exist and be available. The path to the target environment is the network path from the integration environment to the target environment. Each of these two components must be managed relative to the release candidate or the deliverable. Once all these components are configured and ready, the release candidate can be deployed to the target environment.

The automated deployment workflow is shown in the diagram below. It is the logical application lifecycle management progression, only automated for more deployments and shorter feedback loops.

The automation is supplied by the release deployment tool. The right tool needs to not only manage the aforementioned components but also track the deployments completed. A good tool will have an embedded database that will serve as a record keeper for both history and governance.

The hub of governance is compliance. Deployment automation is a repeatable process based on the business deployment plan. The right deployment automation tool will allow you to report on what delivery was deployed and when. It will also capture such information as business purpose, approvals, and requirements. This is key information for compliance reports.

Deployment automation is also a key part of a good security plan. Control over deployment allows control over what customers use and consume. If there is a security flaw in a deliverable, deployment automation supports an audit process to understand why the flawed deliverable was released. Deployment automation also supports a repeatable process to deploy the updated deliverable that resolves the security issue in the best and fastest manner.

Deployment automation has many advantages in addition to what was discussed in this article. However, the most important advantage is that deployment automation delivers value to the business sooner. It also makes it possible to continuously deliver value to the business and fix issues in the least amount of time.

Deployment automation can also support a self-service business model. It may not always be everyone’s method of doing business, but if this is an attractive strategy for you, deployment automation is a good solution. The self-service strategy can shield the release team from planning and scheduling releases.

Automation also drives joint ownership of software products. It is a best practice to limit self-service to activities such as approving, planning, and scheduling deployments. Another good practice is to tightly control the type of deployments that are self-service. For example, self-service can be limited to deployment to a certain machine or image that is part of the testing environment.

These governance tasks include deployment approval, deployment scheduling, and updating the business reasons for the deployment. When using this model, the deployment team configures the deployment automation tool to run the deployment process according to the business requirements.

In order to run a self-service deployment model, the deployment team must build an automated deployment project configured so that it only requires a minimal number of inputs into the deployment tool from the business team. Once those inputs are entered, the business team needs only to execute a few steps to schedule the deployment. Again, the best practice is to make sure the self-service model only allows your customers to schedule a deployment, not execute a live deployment.

Of course, this does involve providing access to the business team of the deployment automation tool. This must be done with thought and planning. You want to provide minimal access while still providing enough permissions for your business team to complete the approvals and scheduling of the deployments.

I have an important financial services client who runs deployment automation. They use it for all of the aforementioned advantages, but they also use self-service. This team has taken deployment automation to the next level. They have shifted key governance tasks of deployment to the business team they support.

My client uses a commercial tool for deployment automation. This tool has a very well-documented API. They used the API to create a custom interface that only exposes functionality they need to approve a deployment and then schedule it.

The custom self-service API application runs through a Java server page. First, the customer logs into the self-service application. They enter the approval for their deployment, then enter business reasons for the deployment. Finally, they enter a deployment schedule. The deployment can be canceled before the scheduled time if needed.

This self-service deployment system has been working very well. The customer’s feedback has been extremely positive. The application deployment team has also found this self-service tool to be very useful, as it shifts governance away from them and to the business team. A diagram of the self-service deployment, where the customer enters approvals and other governance information and the system automatically creates a scheduled deployment, is shown below.

Automated deployment is a strategy for improved software quality and delivering business value on a shorter timeline. Automated deployment supports shorter and more frequent feedback loops, so customers can provide guidance to steer the software product as it is developed. The shorter feedback loops also support stronger methods for managing changes in requirements. If you want to continuously deliver business value and fix issues quicker, you may want to consider adding an automated deployment strategy to your project.