Continuous Deployment

Continuous deployment and continuous delivery… what does this mean ? How do we do it ?

These are great questions and a good place to start this post. Continuous deployment means that I have a scripted way to change the components of my application that generally change while keeping the other components the same which generally don’t change, using a scripted method to ensure the change worked.

Continuous delivery means that I’ve successfully executed continuous deployment in lower environments to prove my deployment works (or show what part is failing from the change) in order for me to update production. In short, continuous delivery means that you can reliably update your production environment in a scripted predictable and testable way. It’s continuous because it’s scripted and we make proper use of the software development life-cycle we’ve defined for our application and it consists of a development, qa and production environment in the least.

How do we make this simple ?
You don’t, because it’s not. You need an engineer to look at the moving parts and make important decisions as to how we put the stack together, how we change it, how we make it work using different production grade technologies (load balancers, distributed computing, elastic clouds, shared storage, etc.. etc..).

What do you mean by “the stack” ?
The stack is EVERY component used to make the application and its versions. An example stack is:

Red Hat Enterprise Linux v5.11 kernel 2.6.18-398
[List of installed system RPMs] [RPM’s versions]
Java 1.7.0_71
Wildfly 8.2
Oracle JDBC 11.2.0.4
App Keystores 1
Configurations 1.3
Leroy Deployment 2.1.4.2
Application War 2.1.4.2
Nagios Client 4.1.8
HA Proxy 1.3.15
Apache Zookeper 3.4.6
Apache Mesos 0.21.1

What we must prove:

  1. Our first environment will test if the given versions of these components can be installed an function on a basic level, and that our deployment mechanism works. Let’s call this “build”. After the application war completes a successful compilation and unit-test run, we will automatically deploy those changes to this environment to test the sanity of the application with the deployment.
  2. Our next environment will have a functioning deployment mechanism from the previous, only now we are testing if all the changes from all the development team members combined into one “Application War” is working and integrating with any other external components we integrate with, let’s call this “Dev”
  3. The next environment after this one will be a dedicated stable environment where a testing team can run manual and automated testing against the stack to prove it is ready for production, let’s call this “QA”
  4. Finally, a robust mirror of production which tests that the artifact the QA team certified will work properly in the same infrastructure as production, let’s call this “stage” or “pre-prod”, some companies may simply use this environment to do QA on to save a step, others may have a legitimate need for a pre-production for beta users or other miscellaneous use.
  5. Now, we are ready to update to production

Once we have pushed our stack full life-cycle and know that we have a working application, we should be able to change versions of any component we like and run the same deployment and tests with (hopefully) marginal changes to configurations and deployment structure. The point that is being made here is that continuous deployment is not simple, it’s engineering work that is done by an engineer. The work is to prove that the stack works and that the stack has been in each environment before it goes to production. From a high level, the stakeholders of the application should understand the general principles used to accomplish continuous deployment.
The other point we desire to make with this article is that in order for this process to work well, the deployment itself needs to be considered one of these components in the stack, expressed as code and versioned in the code repository like all other code. The deployment is an application and must be treated and tested like any other application. Our goal with leroy was to make a universal simplistic language to express the workflow of a deployment as code that will work against different environments (dev to production). Single workflow, multiple environments, properties centrally stored and managed and used to build configuration artifacts as well as environment variables in deployment scripts using the scripting language of your choice. If your language supports reading environment variables or command line arguments, then you can use it with Leroy.

continuous deployment example

Leave a Reply