By Chris Nagele, Founder, Wildbit
We’ve all been there. A new feature has been tested and is ready to be deployed to your servers. That’s when the fear sets in. Am I forgetting any config files? Are we sure it’s going to be deployed to all of our servers at once? What happens if it breaks the site?
This scenario is surprisingly common. Creating a consistent process to deploy your application can be a daunting task. With today’s applications it’s much more than just copying files from your source control to your servers. In most cases, it includes multiple servers, separate environments (staging, production) and extra scripts to manage tasks like clearing cache or setting configs.
The goal, no matter how complex your application, is to allow anyone on your team to deploy in one step.
Achieving this goal is not only liberating, it also encourages your team to deploy more often, reduces trivial mistakes and keeps your entire team (and customers) informed on the status of your product.
A single, consistent process
The first step for a deployment process should be planning out the tasks. For any application, there are a number of steps that must happen before, during and after the deployment happens. If you don’t have an automated deployment tool, these tasks are most likely performed manually by each person who updates your site or application. Some examples include building or preparing the code and files, stopping services on your servers, and pushing the code out to your environment. There are also post-release processes like running automated tests, clearing cache, and restarting services once the code is deployed.
All of these steps should be documented and organized in a step-by-step list. This list then becomes the source for your automation process. Each step should be part of a single process that executes tasks in the right order.
Multiple servers and environments
Once you understand the steps and tasks that need to happen for a successful deployment, you also need to prepare this process for multiple environments. Any new code deployed should first be tested in a staging environment that closely matches production.
A good deployment process should be flexible enough to switch between environments with little effort, allowing your team to choose based on the state of the code. Once the new features are deployed, tested and approved in staging, the process of deploying to production should be just as easy.
In addition to multiple environments, you should also consider multiple servers and the scalability of your deployment process. As your application grows, you should be able to easily include additional servers into the deployment process.
Well informed team and customers
A stable and consistent deployment process is the No. 1 priority. It not only gives developers and engineers an automated method of launching features; it also allows anyone on the team to deploy regardless of technical skills. Involving your team (and even your customers or clients) in the deployment process is just as important.
As part of any deployment process, there should also be a history of what occurred – also known as _release notes_. Anyone on the team should be able to see what was deployed (revisions, files, tickets), when it was deployed and who deployed it. Automating this process greatly reduces communication overhead and improves your team’s visibility into what has changed in the application. Release notes can also serve as a way to keep customers or clients informed on updates.
Some examples of release notes can include email notifications, chat room notices (HipChat, Campfire), and RSS feeds. The best part is that even release notes can (and should) be automated.
It’s not as hard as you think
I’m sure that all of this sounds great, but how do you implement an automated deployment process that your entire team can use? The good news is that there are plenty of open source tools that allow you to accomplish this. Some of them are very mature. Tools like Capistrano, Fabric, Chef and Puppet allow you to build both simple and complex automation around your servers and application deployments.
At Beanstalk and dploy, our goal was to create deployment tools that did not require any complex scripting or a developer to initiate. With both Beanstalk and dploy, you can instantly ship code from your repositories in Beanstalk, GitHub, Bitbucket or even your own servers. We integrate directly with Rackspace Cloud Files and even support Cloud Servers and Managed Hosting through SFTP and SSH access. In addition, we keep a history of each deployment and can notify you and your team through email, Hipchat, Campfire and even custom web hooks. It’s a repeatable process that allows anyone to deploy to one or hundreds of servers in one step.
There is not a single deployment process or tool that is best for everyone. What’s more important is that you find a process that accomplishes the following goals:
- Anyone on your team can deploy in one step.
- You can easily deploy to multiple environments and servers.
- Your team is notified of the deployment through release notes.
If you’ve never had a proper deployment process, achieving the goals above will result in faster release cycles, fewer mistakes and less downtime and a well-informed team that makes better decisions around your code and updates.
This is a guest post written and contributed by Chris Nagele, founder of Wildbit, a Rackspace partner.