Automation is the act of taking a set of manual tasks and writing a program to perform them in a fraction of the time. As a programmer, I believe that if you are performing the same tasks again and again then they should probably be automated by a script. At Enigma we are constantly needing to deploy new projects or updates to projects to our servers so the decision to automate these tasks seems like a no-brainer.
Deployment automation has many benefits, the main two being time saving and a reduction in errors and/or mistakes. As humans, we are extremely error prone, so the less human interaction the better. Using an automated process also allows any team members to deploy without needing a great understanding of the underlying mechanics. The only real drawback to automating the deployment process is that there is a big initial overhead of time required to set up the process, however the time saved in the future more than makes up for this initial outlay.
Here at Enigma our automation processes rely on three technologies. These technologies are Git, Ansible, and Capistrano. They all suit different needs but when used together allow us to create a smooth automation process for deploying servers and projects via just a couple of commands in the terminal.
We use Git for version control, it allows us to store all our projects in remote repositories for easy access and collaboration in teams. Git keeps a full history of all changes made to a project and allows multiple people to work at the same time and commit and merge new code. There is a lot more Git can do to increase workflow and help developers work together, but I won’t go into that today.
Capistrano is a tool used for deploying projects to our servers. Capistrano connects to a server using SSH, or Secure Socket Shell, and then pulls our code from a Git repository and runs the necessary scripts to get the project running correctly. If need be Capistrano is capable to of deploying to multiple servers in parallel. One of the most useful features is the ability to store multiple releases of a project which allows simple instant rollbacks in the case of a failed deployment or undetected bug. Multi-stage deployments are also very useful, allowing you to set slightly different configs for deployment depending on whether they are staging or production environments.
Ansible is used to configure our servers themselves, allowing us to easily install and configure software on the server remotely. Capable of handling all configuration from installing packages to setting up services to running scheduled tasks like Cronjobs. We try to make sure any server changes and configuration are stored within Ansible so that if we have to rebuild or spin up a replica, we only have to run Ansible to get an exact copy of the configuration running.
The approach we’ve adopted here at Enigma is based on using these three methods in conjunction. It means we are able to spin up new servers and deploy projects in minutes with just a few simple commands in the terminal, and the time spent on set-up has been more than worth it in our opinion.
If you've got questions of your own around deployments, or any of the issues touched upon in this post, please drop us a line.
A recap of the main points:
- Takes time to set up, but the time saving more than makes up for initial investment
- Less error prone, steps won’t be forgotten
- Allows any team member to deploy
- Ability to rollback
- Git is a form of version control
- Stores work in a remote repository
- Keeps full history of changes made and who made them
- Ease of collaboration within the team
- Used for deploying projects to our servers
- Easily configured
- Stores releases for easy rollbacks
- Uses Ruby
- Used for managing the server.
- Uses Python
- Installs software and configs
- Allows easy remote management of the servers
- Different playbooks for different types of servers
- Repository stored using Git, to provide a history of changes the whole team can access
- Dramatically simplifies the process of rebuilding a server