Automated deployment is achieved through a tool, or process, that's used to configure an application for consistent, reliable deployment, minimizing developer involvement.
There are many different flavors of automated deployment. In my mind, the simplest form of these allows developers, through minimal configuration, to describe their application's infrastructure with a single config file and deploy with a single command.
In this article, I'll compare the process of manual or traditional application deployment, with the use of an automated deployment tool to accomplish the same tasks.
This article won't go into the nitty-gritty details of how to deploy an application since there are nearly endless ways to configure and deploy the countless types of applications. Instead, I'll give you an overview of different pieces of the deployment process and what you would have to know, in general, if you were going to do it yourself.
Where to host the application
The very first thing you need to consider is where you're going to host your application. There are so many options, it's easy to suffer from choice paralysis.
While most options are probably borderline preference, it's something you should take some time to think about.
Remember, without an automated deployment platform, moving hosts is difficult at best. You'll likely need to reconfigure your entire application to run on the new infrastructure.
When considering your infrastructure you'll need to first think about the operating system (OS) you'll use (most likely some distribution of Linux).
Once you've chosen your OS, you'll need to install all the required packages to run your application. This includes languages, databases, misc. libraries, etc.
After the initial setup, you'll always need to keep on top of your environment. You'll need to make sure you're always up-to-date with the most recent security patches, and newest versions of all of your packages.
You'll also need to consider who will have access to the server, and set up corresponding users and user groups. Who will be allowed to do what, and how will they have access?
Finally, you'll need to configure any networking, proxies, firewalls, redundancy, failover, internal (or external) network access... the list goes on (and on).
You'll likely want to integrate with some continuous integration/continuous delivery service.
You can configure many of these to automatically deploy your application after all the tests have run successfully so you'll need to figure out where exactly that sits, and how it interacts with your application and infrastructure.
You'll need to decide what deployment strategy you're going to use (FTP, SFTP, rsync, SCP, etc.) and what you do if something fails, or explodes, how do you roll it back or revert the changes?
If you're running a fairly large application, how do you deploy to multiple redundant servers?
Consider what it will take to scale if your application grows, or you get a sudden spike in traffic. How will you add servers to your network? How you handle database migrations? How will you minimize downtime?
In modern web applications, encryption is becoming the standard. This is handled by TLS/SSL certificates that you have to install and always keep up-to-date.
The cost of configuring these incorrectly is that browsers won't load your site, and will inform your visitors that you are not secure.
If you've got subdomains you'll need to make sure you set up a wildcard (*) cert or traffic to them wont get encrypted.
You'll need to make sure that your domain is correctly pointing to your application. This will most likely involve the use of CNAME's and/or A Records.
Last (but not least) is all of the "extra" stuff to consider. Logging, load balancing, proxying, monitoring, ACL, etc.
To be honest, this barley scratches the surface of everything involved in configurating an infrastructure to host an application, and I didn't even get into any of the actual details for any of the topics...
When considering automated deployment, there are many different tools that could be used at different stages of the process.
On one end, you have tools like Ansible, Jenkins, SaltStack, or the myriad of others that have the ability to auto-deploy an application.
These tools, however, are more DevOps-centric and focus on the beginning of the process and are geared towards infrastructure creation, configuration, and deployment (not application).
With these you still have to know how to configure your infrastructure, they just help automate it.
Right in the middle, you have continuous integration/continuous delivery (CI/CD) services like TravisCI, CircleCI, and others that offer automated deployment.
Again, however, they focus on the middle of the process. Testing your application before you deploy, with the option to deploy for you.
At the end of the spectrum, you have PaaS. After you've developed your application you deploy to a PaaS and they do all the work of creating and configuring your infrastructure for you.
This approaches the ideal scenario when looking at automated deployment, however, there is still a disconnect.
From Beginning to End
Ideally, you want something that provides a complete development to production workflow. Once you know where you want to host your application, you simply describe its infrastructure and deploy.
Nanobox, for example, is the only automated deployment platform that considers all aspects of application deployment. From beginning to end.
Using Docker to provision a local development environment for each of your applications, Nanobox provides isolated, consistent dev environments you can reliably deploy when ready.
With a simple config file, the
boxfile.yml, at the root of your project, you can
nanobox deploy and Nanobox will build an entire infrastructure on your host of choice (AWS, Digital Ocean, etc.).
Nanobox bears the burden of implementing all the complex details mentioned above so that application developers don't have to. You can focus on developing your application, and easily deploy it.
Automated deployment is very appealing to application developers because it allows them to cut out the middleman (DevOps) and deploy their own applications. No need to get buried in the complexities of deployment. You don't have to hand your application off to someone and hope they can deploy it correctly. It just about you and your app.