Vikas Gupta: Software architect

Automate your software delivery

Posted by Vikas Gupta on January 20, 2013

If a customer wants to add a feature/idea to a product, the time that it will take to release a feature to the market will depend upon the maturity of processes and practices employed by the software delivery team that works on it. The lesser time it takes, the better it is.

But, how can we reduce the time it takes to deliver software? What are the limitations of the traditional software delivery process? How can automating the various stages of software delivery process reduce time to market. In this post my attempt is to introduce the concept of Continuous Delivery, which in a nutshell is automate everything which you can in your software project. I will also list some of the anti patterns of software delivery. So, if you see any of these in your projects, I think you have an opportunity to improve. This post will the first in the series of posts that I am planning to write on Automated software delivery process. In the coming posts, I will discuss more concrete advice on various phases of software delivery lifecycle.

Common Release Antipatterns

  1. Manual Deployment: Manual deployment is time consuming. During software release, most of the times it is carried out by a bleary eyed individual sitting in the front of the computer 1 AM in the morning. He does that 1 am in the morning because testing team certified the build 12 am in the night. He takes time because he is following a outdated deployment document, which a developer failed to update. Therefore, the time he should be spending in his cozy bed is spent in turning caffeine into working application.
  2. Manual configuration management of environments: If your deployment in one environment is working, but failing in another or different machines in a cluster are behaving differently or you have to log into the production environment to modify configuration, then you are managing your configuration manually for various environment which can be time consuming and can add to the time it takes to release software. The process is also error-prone as it would be difficult to audit the changes made to different environment in case of errors.
  3. Deploying to the production-like environment late into the project: Waiting for the development to complete to deploy the software on the staging environment is risky as often bugs discovered at this stage would be difficult to fix. It is a no-brainer.

All the antipatterns mentioned above makes the software release process boring and complex. On the other hand, it should be low-risk, frequent, cheap, rapid, and predictable process.

The goal of every software team should be to have high level of automation of testing and deployment and comprehensive configuration management to deliver push-button software releases to any environment.

How can we meet our goal

Our goal is to have low cycle time and high quality for our software. In order to achieve this, we should

1. Be able to get some feedback of every change: A software application is composed for four components: code, configuration, host environment and data. If any of them change, it can lead to the change in the application behavior. Whenever any of these changes, the software team should be able to get feedback about the change. The feedback should include

  • whether the code is compiling
  • unit test cases are passing
  • test code-coverage and quality metrics are met
  • automated acceptance tests are passing
  • some manual exploratory testing is done

2. Get the feedback quickly: Automating build and testing process is a resource intensive process. So, we should provision adequate infrastructure for this process so that it takes less time to build and test the application.

3. Act on the feedback: Everybody in the team should be involved in the feedback process and they must act on that. This required discipline and planning. Also, team should collaborate with each other to act on the feedback.

What should we automate

There is nothing set in stone on what we should automate. Anything that can be done by the computer can be automated. However, we need to analyze the cost aspect of automation as well. So, in general, if you see yourself repeating something manually in the project, it certifies as a good candidate for automation. As a guideline, we should automate

  • Build process
  • Code Reviews
  • Testing
  • Deployment
  • Any documentation which can be generated from the code.

Benefits of automation

Well, automating the build and release process is an investment. It requires time to setup and discipline to make sure it works in the long run. It is therefore paramount that everyone in the team is aware of the benefits. So, what are the benefits

1. The principle benefit is that we reduce the delivery process time and deliver high quality software.

2. It empowers team. It is a loaded statement. But, it means the members of a team can work independently. For instance, to deploy a version of a software, testers do not need to depend on the developers of build experts. Since, the build is automated, one can deploy the software whenever they want with freedom.

3. It makes the software release process error free. With no manual intervention, the entire process is error free. Since everything is under version control, it is easier to audit the results in case of any errors.

4. It lowers stress in the team, specially whenever the release day is approaching. We have seen how small changes come during the last moments. Having everything automated reduces stress in incorporating those changes.

5. It is easier to deploy the application on different environments.

6. Any code change is a potential release candidate.  There is no need to wait for traditional alpha, beta releases.

In this blog, I have discussed the problem of not automating the software release process. We also discussed the goal of automation and benefits of it. To sum up, I would say, to achieve high level of quality in quick time, we should

  • Automate build and release process
  • Keep everything (code and configuration) in the version control
  • Build quality and testing as part of development process. Don’t wait for the end.

In the coming posts, I would like the share the ideas used by high performance “Agile” in configuration management, version control, automation testing and other best practices.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: