CI Tools and Best Practices in the Cloud

Continuous Integration

Subscribe to Continuous Integration: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Continuous Integration: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Continuous Integration Authors: Stackify Blog, Aruna Ravichandran, Plutora Blog, Dalibor Siroky, PagerDuty Blog

Related Topics: Continuous Integration, Application Performance Management (APM), DevOps Journal

Blog Post

Continuous Delivery 101 By @Dynatrace | @DevOpsSummit [#DevOps]

Continuous Delivery embraces automated deployments in various stages of the software delivery process

Continuous Delivery 101: Automated Deployments

The ability to automatically and reliably deploy entire application runtime environments is a key factor to optimizing the average time it requires to take features from idea to the hands of your (paying) customers. This minimization of feature cycle time or feature lead time is, after all, the primary goal of Continuous Delivery. Today, I will introduce you to the whys and wherefores of deployment automation and discuss its importance for driving the adoption of DevOps.

The Power of Automated Deployments
Production servers can be described as "grown works of art": An unknown number of commands have been applied by various people over time, often in an ad-hoc manner, and written documentation is commonly outdated, if at all present.

Due to the inability to fully understand and entirely reproduce such environments, companies periodically create full server backups to be prepared against server loss. Still, restoring an environment from backups may consume considerable resources with uncertain success (how frequently do you verify your backup strategy and assess the mean time to recover?) and can by no means be compared with the flexibility and agility of being able to rapidly and reliably re-create any environment on demand - from development to production:

"Enable the reconstruction of the business from nothing but a source code repository, an application data backup, and bare metal resources."
- Jesse Robbins, CEO of Opscode

Continuous Delivery embraces automated deployments in various stages of the software delivery process and identifies manual deployments as one of the common release anti-patterns. It demands to let computers do what computers do best. Therefore, over time, all deployments should be fully automated to make releasing software a repeatable and reliable push-button activity:

  • Manual deployments are not consistent across environments
  • Manual deployments are slow, neither repeatable nor reliable
  • Manual deployments require extensive documentation (often outdated)
  • Manual deployments hinder collaboration (conducted by a single expert)

In combination with agile development practices and a sound suite of automated tests, deployment automation allows you to minimize feature cycle time or feature lead time by reducing waste. No doubt, time-to-market is important if not vital: you will not know whether your users will adopt a new feature before you actually let them try it out, and the sooner you deliver the earlier you can start to make money out of it:

Create value quickly - Deployment Automation helps minimize your Feature Cycle Time

Another common anti-pattern is "deploying to a production-like environment only after development is complete." This means there can be almost no confidence that a particular software release will work successfully for end users if it has never been tested in a copy of production.

We will now examine how deployment automation fits into the concept of a Continuous Delivery deployment pipeline because it lays an important foundation for establishing a high degree of confidence through the automated provisioning of production-like environments.

Deployment Automation in the Continuous Delivery Deployment Pipeline
As Jez Humble and Dave Farley put it in their standard book "Continuous Delivery," "A deployment pipeline is, in essence, an automated implementation of your application's build, deploy, test and release process."

The pipeline concept is in analogy to Lean Manufacturing, where a production line is stopped whenever a defect is detected along its way. The problem is then addressed with immediate and utmost attention and corrective measures are taken to minimize the possibility of making the same mistake ever again (Continuous Improvement) - a principle that is also important in Agile Software Development.

An exemplary Continuous Delivery Deployment Pipeline

Here is what a deployment pipeline could look like for your application. In general, the process is initiated whenever a developer commits code to a software repository inside the version control system (VCS) such as Subversion or Git. When the build automation server, which acts as the pipeline's control center, such as Jenkins, observes a change in the repository, it triggers a sequence of stages that exercise a build from different angles via automated tests, but terminates immediately in case of failure. Only when a build passes all stages it is regarded to be of sufficient quality to be released into production.

Stage #1: Commit Stage
In the commit stage, the build automation server checks out the software repository into a temporary directory, compiles the code and executes any quick running, environment-agnostic tests (mostly unit tests). After that, release artifacts such as installer packages are assembled and documentation is generated.

Stage #2: Acceptance Test Stage
In the acceptance test stage, deployment automation scripts (executable application runtime environmental specifications) are executed to create an environment that is dedicated to the remainder of this stage and that is highly similar, not necessarily identical, to the production environment. Release artifacts are deployed and smoke tests are executed to verify that the application and related services are up and running. Finally, automated acceptance tests are run to verify the application at the business level.

Stage #3: Capacity Test Stage
Similar to stage two, but automated capacity tests, typically load tests, are run to verify that the system can serve a defined level of service under production-like load conditions. Here, it is assessed whether the application is fit for purpose from a non-functional perspective, mostly in regards to response time and throughput.

For stage 4 & 5, and for further insight, click here for the full article.

More Stories By Martin Etmajer

Leveraging his outstanding technical skills as a lead software engineer, Martin Etmajer has been a key contributor to a number of large-scale systems across a range of industries. He is as passionate about great software as he is about applying Lean Startup principles to the development of products that customers love.

Martin is a life-long learner who frequently speaks at international conferences and meet-ups. When not spending time with family, he enjoys swimming and Yoga. He holds a master's degree in Computer Engineering from the Vienna University of Technology, Austria, with a focus on dependable distributed real-time systems.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.