Businesses today expect speed — from the runway until launch to the interval between the first and second releases. But, speed without quality can impair a brand’s credibility. The DevOps lifecycle enables businesses to pursue a culture of rapid development releases with confidence.

As businesses assess current success and plan for next year, establishing a successful DevOps culture and process represents the keys to success for many.

Benefits of a DevOps Lifecycle

Businesses look to DevOps to achieve some of the sacred tenets of sustained software development — speed, security, and scale.

By automating elements of the software lifecycle, teams are able to deploy to production at any time — removing hurdles that can slow the progress and productivity of development.

Security Assurance

According to the Puppet “2016 State of DevOps Report,” businesses successfully implementing DevOps can “deploy 200 times more frequently, with 2,555 times faster lead times, recover 24 times faster, and have three times lower change failure rates.”

Many DevOps teams push early integration to save time and increase software testing further forward in the process.

Higher Productivity

The Puppet survey also found that organizations who master the DevOps lifecycle also “spend 22 percent less time on unplanned work and rework,” freeing time for new code or feature development.

Designing a DevOps Process

Teams looking to embrace and implement a DevOps lifecycle must look to the business need and shape the process and implementation around it. Requirements, the size of the solution, and expected user volume all factor into the decision.

By passing code through a series of sequential tests and approval, development procedures within a DevOps culture are tightened and the resulting code deployments made more accurate.

Most code built and tested by a team with a strong DevOps culture passes through four or five environments. As each version of the build is promoted, more users from the development and client teams interact with and test it, thereby providing multiple access points to find and fix bugs. If the code doesn’t meet the standards defined by the team along the way, the build is discarded.

Environment Types

Development. The code is built on local machines by developers and engineers.

Test. Here, quality assurance analysts or software testers vet the code to ensure it performs according to the documented requirements.

Staging. Quality assurance analysts from the development team and client representatives work with and test the code.

User Acceptance. The developers, testers, and client validate the performance of the code.

Production. From this external-facing environment, code driving functionality is made available to end users.

We break down general environment types by size and load, but not all of them are fully automated. Components of the “Advanced Web App” implementation are a common DevOps practice to speed up the time from code birth to production environment deployment. While the first two types are pretty simple, Infrastructure as Code (IaC) is vast. IaC is based on tools that can create all types of environments (dev/stage/uat/prod) from code. The code in question is kept again in source control repositories, and thus, it is versioned and error prone.

Simple Single App

• Source Control: Yes
• Scaling: Manual
• Services Used: Amazon EC2/Amazon Simple Storage Service (S3)/Amazon Route 53/Amazon Simple Email Service (SES)
• App Architecture: Single Instance
• CI/CD: Manual
• Containers Used: No
• Expected User Load: Low

Simple App DB-Int

• Source Control: Yes
• Scaling: Manual
• Services Used: Amazon Simple Storage Service (S3), AWS Elastic Beanstalk, RDS, Route 53, CloudFront, SES, SNS, CloudWatch
• App Architecture: Stateless Application/Web Farms
• CI/CD: Manual/Opt Jenkins
• Containers Used: No
• Expected User Load: Low

Advanced Web App

• Source Control: Yes
• Scaling: Auto
• Services Used: EC2 two or more, ElasticBeansTalk, ElasticLoadBalancer, Encrypted RDS instances, RO RDS instances, ElastiCache, EFS, Lambda, Route53 (OPT), CloudWatch, S3, SES, SNS, CloudFront
• App Architecture: Stateless Application/Web Farms
• CI/CD: Recommended Jenkins
• Containers Used: Opt Docker/other
• Expected User Load: Medium-High

Infrastructure as Code

• Source Control: Yes
• Scaling: Auto
• App Architecture: Mixed services, 20+ instances/Stateless Application/Web Farm
• CI/CD: Jenkins
• Containers Used: Recommended Docker
• Expected User Load: High-Very High

Our Preferred DevOps Tools

AWS Services

• CloudFormation
• EC2
• S3
• ElasticBeanStalk
• RDS
• EFS
• Glacier
• IAM
• Certificate Manager
• VPC
• Route 53
• CloudFront
• ElastiCache
• SES
• SNS
• Lambda

Continuous Integration and Delivery Tools (CI/CD)

The following tools can automate integration and delivery. Most teams use a project tracking system integrated with the build process. We recommend JIRA. Additional systems beyond those listed can be used for test management, container management, or bulk administration tools

• Jenkins
• Docker
• Puppet
• Cloud services (see above)
• Build tools, Jenkins or similar
• Build automation: Java, Maven/Gradle, .NET – MSbuild, and others for Ruby or another technology

What Makes a Team or Project a Good Candidate for DevOps

A number of variables must be considered before implementing a DevOps program. In order to create a process that includes effective development, testing, integration, and deployment, teams weigh the following most common factors:

• Project size
• Project duration
• Customer demand
• Release cycle and effort spent for manual work
• Breadth of knowledge and team background

Image Source: Jason Blackeye on Unsplash