Continuous deployment model

Standard

We’re moving to continuous deployment; What is it, how does it impact the organization and how do we get there?

Early 2010, our DIY fashion company had a ‘heartbeat’, in which every Wednesday, just after lunch, we would release a new version of the website. Although scripted, this climax of a weeks work was always a stressful time for the developers. We had to get the entire staff to agree on the release window and run numerous tests before and afterwards. Due to the hassle of putting things live, some companies release less often, monthly or perhaps every month. Why such a fuss for a release?

Continuous deployment (CD) minimizes the time spent of putting new code to the live users, in production. This is done by automating each step up to deployment, avoiding human intervention where possible. Leading to less stress, which is good :-). In the last years, we’ve gone from ‘waterfall’ method, with an infrequent release, to a bi-weekly release. The next logic step would be to be continuously improving the site, without the ‘overhead’ of releasing software. This is not only a mentality change for the IT department, it also changes the entire organization as idea’s can be implemented in a swiftly (scrum) matter and less ‘project planning’ is involved.

CD leads to a number of advantages:

  1. * Due to automated testing of code combined with reviews quality will be improved
  2. * New ideas are realized quicker; as you can deploy an addition the same day!

To achieve this, we had a scan by Xebia which identifies the various ‘levels’ of automatic deployment. I think it’s an insightful overview and thus I wanted to share it here:

DevOps Monitoring Testing Provisioning Deploying Building
Level 5 Complete Operations and development are both part of the same multidisciplinary delivery team and share responsibilities. Monitoring of business level quality metrics. Predictive failure monitoring.
Monitoring data is used actively to improve the system.
100% fully automated tests all the way to production Self Service portal for requesting environments.
New environments are created with each new release. Network automatically configured.
Continuous end-to-end deployments. End-to-end automated gated builds.
Level 4 Advanced An envoy of operations works along in project, an envoy of development works along with operations. Application Health and Build/Deploy dashboards available to teams, provides continuous insight into quality, health and performance metrics. Automated dynamic quality tests like security scans, functional and performance tests guarantee quality of code. Environments created and torn down by a push of the button. Supporting systems automatically configured Test-gated deployments of end-to-end applications. Deployments occur over multiple environments. Central build environment.
Teams actively reuse generic components in a secure and controlled manner.
Level 3
Average
Development and operations work together when this is required. Monitoring of software quality, application performance. Reports accessible through dashboard. Automated static code and security analysis after code check in. Environments are identical. Operating System is virtualized. Several tools used to provision and configure an environment. Environments are identical. Roll out of applications performed by a push of the button. Auto- deployment to D, T, A and P. Build on commit. Archived components are made available for reuse by other teams.
Level 2
Beginner
Code accompanied with release notes with which operations should install and manage the application. Monitoring of application log files for errors. Reports generated on demand. Automated tests are initiated as soon as code is checked in. Tests are focused on unit /component testing only. Scripted installations per component for each environment. Supporting systems manually configured. Self service deployments to development and test. Automated builds are performed in a central area and activated manually.
Level 1
Base
Operations engaged at the end of the project. Monitoring of system metrics (CPU, disk, memory, process). Reports accessible to Operations. All tests require manual activity. Some tests are automated but have to be initiated by hand. Manual installation and configuration of Network, OS and software for middleware, databases, application servers, etc. Deployment through execution of separate deployment- and db scripts. Manual configurations and installs / env. Builds are performed on local workstation by use of one or more separate build scripts.

 

developing

Our team scored at level 3 during the scan some time ago. We’re working on achieving level 4 and later 5. For one, we puppetized our servers this year, allowing central management of their configuration, easy deploy of new machines.

At the early stage of the project, we introduced a so called building server (Jenkins) and put a monitor link on a large tv screen (photo) on the workfloor. This had immediate effect, firing hundreds of pre-written unit (code) and regression (tests on the frontend UI) every time a developer commits a piece of code to the ‘default’ (shippable) branch in our code repository. This saved our Quality Engineer a lot of time. It also made the process more visual, our team was able to see who broke the code. Next we’re scripted the deployment up to production. Here, human interference is still required but this is something we can let go once we trust the system more and more.

Write code > commit > pull request, review (manual) > build > package, staging > production > post deploy test

The final result will be a flow where a programmer will work on a new feature or bug in an own environment. (so called branch) Once the work is complete, the code will be pushed to the ‘default branch’; which will initiate a ‘review’ moment where another developer has to approve the change. The code is then on the default branch, which should at all times be ready to go to live. At this time, our build server will perform numerous unit and regression tests, upon which, the code is deployed to production. On production, another test is done to ensure the quality.

We still have some steps to go, but already reap the advantages of this system today.

Leave a Reply