More and more, deployment automation is becoming less of a luxury and more of a requirement for software development teams that are looking to remain competitive in the current marketplace. It allows you to deploy your applications across the various environments in the development process—all the way to production—in a more efficient, reliable, and predictable way. At the end of the day, solutions that automate your software release processes improve the productivity of both the Dev and Ops teams and enable them and the business to develop faster, accomplish more, and ultimately build better software that is released more frequently and functions more reliably for the end-user.
While there are many benefits to automating your deployments, there are a number of areas you should give thought to before implementing a deployment automation solution as part of your software development and release process.
Primarily, an automated deployment solution allows you to write your processes once, get them exactly the way you want, and then automatically run them—and reuse the procedures every single time you deploy a new application or update across different environments.
The Benefits of Automated Deployments
With that in mind, let’s start by taking a look at some of the biggest benefits of deployment automation and why you should consider making it part of your development process.
First, automated deploys are repeatable and much less error-prone. Once you have your app update ready to go, it can be easily deployed in the same process, without the possibility of someone accidentally typing the wrong thing when configuring a step.
Second, automated deployments mean you can give anyone you desire the access to deploy software. Any stakeholder in the project will have the ability to push the launch button (with the right security or permissions mechanisms in place). You won’t have to rely on just a handful of employees with intimate knowledge of the fundamental code of the update in order to execute a deployment. Developers and QA people, and in some cases even business owners, could easily push an update to their respective environments, rather than having to “get in line” and wait for Ops to update their infrastructure and application, while not being able to move forward with their tasks in the meantime. Essentially, the knowledge of how to release your software is in the design—not in the developer’s brain that coded it.
This is particularly important because with manual deployments, the ability to deploy an update is often in the hands of the one or two people who built it. If only they have the permissions necessary to execute a deployment, it can leave the company in a lurch if there is any kind of pressing need to take immediate action, such as fixing a bug in production or releasing more frequently to stay competitive in the market.
Another huge benefit to automated development is that engineers’ time is freed up to spend on actual, meaningful development, rather than scripting, doing manual deployments, or fixing failed processes, which should have been handled by an automated process. Performing a manual deployment is a time-consuming and labor-intensive process, so if you are relying on manual updates for your software, that means you have folks like your developers and testers spending their time deploying updates when they could be spending their time building the “next big thing” that will make your software better.
Lastly, automated deployments have what’s called a low overhead. While they take a bit of work to initially set up, the long-term overhead is much less than manually deploying updates. This means you can release more software updates, more frequently. This is desirable for many reasons, some of which we’ll go over later in this article.
Considerations for Implementing Deployment Automation
Now that we’ve taken a look at some of the benefits of deployment automation, let’s talk about some best practices and considerations to take before you move forward.
One thing to do is take a look at the dependencies of your code and application. Dependencies are when the functionality of your application depends on something else. For example, your web server application uses a database hosted elsewhere. If the data in that database is changed or columns are deleted, the application’s functionality will be impacted. You need to understand what depends on what, and where your changes might have an impact down the line.
Start your project by creating a dependency map showing where the connections are between your different applications, databases, code, and related infrastructure. Then, when you look to model your release, you’ll understand how each change might impact other processes.
It can also be helpful to make sure your applications and services are backward-compatible, which makes handling dependencies easier because you avoid versioning issues. If versioning comes into play, you just created a dependency issue you could have otherwise avoided.
Another area of consideration is governance and compliance. Basically, what rules do you need to adhere to with your application? The rules of the game vary wildly depending on your company, your product, and your space. At a small startup with a team making a web app, there probably aren’t too many rules to worry about in terms of which team member has access to what, or what audit tracking needs to be put in place. On the other end of the spectrum is software used by financial institutions or the military, where there are massive walls between environments and access to code and data that can’t be crossed.
Start by understanding the actual compliance and security requirements. Even the most seasoned developers and IT professionals often overlook this step and jump right to the tools setup without giving due diligence to answering the question, “What do I really need here?” Once you figure out the real requirements that are necessary for your specific application, you can map them out, then apply the tools. That way, you don’t end up building any more governance and compliance systems (aka, doing more work) than is absolutely necessary.
Once you’ve made the decision to automate deployment, it’s a good idea to think about your rollback strategy: what you will do if something doesn’t go exactly the way you anticipate. The truth is, at some point, something is bound to go wrong. While it’s easy to copy over an old set of files, some changes are absolutely irrevocable. Once you drop a column in your database, there’s no “undropping” it, so to speak. So start by being aware of changes you can and cannot roll back and make your plan from that point forward.
How you address failed deployments or the need for fixing bugs in the software quickly is an area where frequent deployments are hugely beneficial. For one, the more often you are releasing updates, the higher the likelihood that the changes to the application between each release are small and more manageable. If something goes wonky, you can quickly identify where the error is coming from and correct it. If you are releasing massive, infrequent deployments, you’ll have to wade through tons of code to figure out where the error is coming from. This potentially means more downtime and a much worse user experience. Aside from this very real benefit, frequent deployment also shows your users that you are working to improve their experience and the product’s functionality on an ongoing basis. It adds very real value to your software.
Overall, deployment automation has many benefits. With careful planning and execution, implementing automated deployment will make your development process faster and more user-friendly for all stakeholders—from developers and QA to release engineers, database administrators, and IT operations—and, ultimately, the end-users.
See Anders Wallgren at DevOps West 2016. Click here to view the program schedule.
