The process of getting completed feature or bug fix code from the development environment to your web servers is web software deployment. We have been deploying code in various ways, more than a decade back we were used to uploading our files using File Transfer Protocol (FTP). I would not consider copying files from the development machine to a web server a form of automated deployment, it was a necessary evil at that time.
If you still use FTP like 22% of Nepali developers did in 2015, you need to move on. In this post, I will briefly mention some deployment tools and try to analyze their pros and cons. Still, as the title reads the best automated deployment tool is the one that best fits your needs.
Web application deployment needs some pre-defined steps to be done so that the software changes are shipped from the development environment to staging/production environment. It is done so that the changes are available for customers/users to use the new features developed by the engineering team. If some or most parts of your deployment process is manual it is not automated deployment. For example, if you ssh into your server and do a git pull it can’t be considered automated deployment process.
Automated deployment is a form of deployment where the defined steps for shipping code from a development environment to staging/production environment is a one-step procedure and fully or partially automated.
In my opinion, automated deployment is a language/framework agnostic need for every application as it saves lots of time. It can be one of the first steps towards a useful DevOps culture. Both the development and system admin/devops team can work together to automate things. It will also open doors to further automation like continuous delivery, for example your tests pass on a CI service and the code can be deployed automatically to your staging servers.
It should have the following characteristics :
It can be triggered by just one action, like one command on the command line and it will do the job.
The steps will be pre-defined, reproducible and predictable.
There is little or no human intervention from the start to the end.
It should show the deployment progress as it happens, better feedback
It should be atomic, which means either all the steps are completed or nothing happens.
Some good to have features for automated deployment tools are
It should be able to deploy the same code to multiple servers
Each deployment should be done from a given branch/tag/commit of a Version Control System (VCS) like git
It should trigger notifications in the form of email/chat message
Everyone should be able to view which branch/tag is deployed
When a deployment is in progress, it should stop other deployments to start
Rollback of the last deployment should be easy and fast.
Lets look at the free tools available if you are starting automated deployment moving away from your manual methods:
- Capistrano - written in Ruby
- Fabric - written in Python
- Mina - written in Ruby
- Rocketter - written in PHP
- Deployer - written in PHP
I cannot give you a clear-cut winner from the above choices, it will depend solely on your needs. I can describe briefly the two tools I have used do. I have used Capistrano and Fabric. Let’s look at how they differ.
Capistrano written in ruby has been around as an automated deployment tool for years, it is quite stable and has support for lots of languages and frameworks from Symfony to NodeJs etc. You can get more information about it from this podcast and the official docs.
The good thing about Capistrano is it already has a defined flow on how to deploy applications.
If you can understand the flow visually. You can learn how to make/edit a recipe and structure your tasks you are done. Another good thing about Capistrano as it keeps versions of releases and does a symlink switch when the current version is ready. Rollback is fast because it is just a symlink switch to the immediate old successful deployed version of the code.
Fabric written in python is also an old player in the automated deployment domain. Reading it's docs is highly recommended. You can also get deployment scripts for some applications. The main difference is Fabric is more like a remote command runner.
You get a clean slate to structure your deployment process as you want compared to Capistrano. You can write your deployment commands and run it in the sequence you want.
It gives you the freedom to structure your deployment process. You choose the sequence of tasks you want for your deployment procedure.
Generally, other tools are based on Capistrano style deployment, some say they are faster than Capistrano because they batch the ssh commands and run them once. The basic idea does not change. I cannot personally endorse any other tool as I have used them on my own.
If you are already doing automated deployment you can look at making it even easier, like deploying from a Chat interface like Hipchat or Slack. It is termed as ChatOps where one can instruct a bot to deploy an application. If you don’t want to go the chat path, you can even build a web interface to trigger deployments like Samson by Zendesk.
If you have your tests running you can even explore continuous delivery.
In 2018, I would suggest having a look at Docker.
An early warning though, Docker, K8s and Helm setup might take you some time. The time and resources spent will give higher returns in the future, especially for bigger teams.
You will decide to choose the right deployment tool that fits your language/framework, application, and team needs. Try choosing a tool that will do the job well and can be used for a long time without significant problems.
If you want to deploy a big application, want stability and structure go for the safer option like Capistrano. If you are just starting with automated deployment for a smaller application and want to automated deploy with your custom flow use Fabric for its flexibility.
Choose the right tool and get started with automated deployment. Say bye bye to FTP and doing ssh into a server then
git pull origin master. Let's get started!
Originally published at geshan.com.np.