Just a few years ago, containers were barely an idea. Now containers are coming to the forefront of development thanks to the rise of Docker. While there are still some bugs to work out with containers, we feel that containers are the best way to streamline and error-proof a production deployment.
When done correctly, software development follows a set of steps to ensure that code being designed on the machines of software developers runs the same in production.
First, code is developed in a “dev” environment which isn’t live but which should mirror production as closely as possible without hindering development. The dev environment is normally distributed between developers using tools like vagrant to ensure consistency.
Then the new code moves into a staging or acceptance environment, which is often live only to internal users like the development, QA teams, and some business stakeholders. Finally, if the release makes it past testing, it is moved into a live production environment and becomes accessible to external users (in other words, your customers).
This ideal three-phase step has become the best practice, but it’s certainly not the norm. There are still companies who work directly in and deploy directly to a live production server. And even worse, there are many more who have difficulty keeping their separate environments in sync. Therefore, code tested in a QA environment may still fail or cause issues once deployed to the fully live environment.
This is a time consuming and expensive occurrence that simply shouldn’t happen. For some companies, even a few minutes of downtime can mean thousands of lost dollars of revenue.
In our experience, the three development environments are not enough to prevent deployment issues. One big reason for this is that each change to production has to be pushed individually, with the risk of code, dependency, and file conflicts with each deployment. Minor changes that aren’t mirrored across environments can cause huge issues. If a mistake is made, the mistake is reflected over the large number of servers are tied to production. Even worse, when the code changes are back-end in nature, such as database changes, the end result can be catastrophic with long running database rollbacks being necessary to correct the problem.
The solution we’ve had the most success with is to use a container service like Docker. Docker allows us to apply code changes, package up the and mirror the staging environments, and then test them as if they were in production. We then take that exact same container from staging and move it into production with full confidence it will behave in the exact same manner it did when we were testing.
This effectively creates an atomic unit that represents the application thereby eliminating conflicts and inconsistency. When implemented correctly, Docker containers are almost guaranteed to work in production exactly as it did in staging. Containers eliminate unexpected downtime and errors, saving everyone time and money and keeping uptime statistics high. Users are happy, stakeholders are happy, and the development team can go on doing its job of continuing work.
If bugs do slip by QA into production that weren’t detected in staging, rolling back to a previous version of an application is as simple as replacing the new container with the old one in full confidence the previous version will work exactly like it did before.
We use Docker for almost all of our software projects. Interested in seeing how Docker + Agile can make a difference? Contact us today for a no obligation consultation.