Role of Pipelines in Continuous Delivery

The Role of Pipelines in Continuous DeliveryMandi Walls | Technical Community Manager, EMEA |

[email protected]

Hi!• Mandi Walls• Technical Community Manager for EMEA• @LNXCHK• [email protected]

mailto:[email protected]

Let’s Talk About Pipelines

What Do We Mean by Pipeline• The workflow teams use to get changes created and published• The processes and services a set of code has to pass through to reach

production Dev, Build, Test, Stage, etc

• Looks a bit more like an assembly line with stations dedicated to specific work

• Often referred to in Continuous Delivery environments, but not restricted to CD

Why Do We Need Pipelines• All changes must pass through the same requirements• All people making changes use the same workflow• All changes face the same rigor before being promoted to the next

step• Promotes high-velocity throughput for change• Automate steps so they aren’t forgotten• Reduce risk through predictability

What Does Your Workflow Look Like?• Source of pain and angst• Easy to subvert if you “know the right people”• Full of checkboxes and ceremonies that result in questionable value

Fears for Bad Workflow• Change isn’t documented until it gets to the “change review board”• Heavy workflow requirements slow down faster teams• Security and performance teams aren’t involved until after install, if at

all• People find ways to get around the workflow checkpoints to get work

produced faster Who knows what testing that stuff might have gone through???

• No one wants to pay for full testing and integration environments Are they really more expensive than having a defect escape to production?

• People forget stuff, steps get left out, the results are inconsistent

Your Pipeline Should Help Meet Your Goals• Minimize escaped defects• Aid MTTR• Ship new features faster• Fix bugs, respond to user issues faster• Provide a record of changes made, who made them, and when they

were installed

Characteristics of a Good Workflow• Allows for some customization between projects, but everyone still

hits all checkpoints• Portable between projects• Simple entry point for change to application or infrastructure• Optional human gates for approvals by release management, product

management, marketing, etc• Testing and integration environments represent “real world” and are

easy to maintain

The stages are fixed, and each stage has a fixed set of phases

VERIFY BUILD ACCEPTANCE REHEARSAL DELIVEREDUNIONAPPROVE DELIVER

LintSyntax

UnitSecurityQualityPublish

LintSyntax

Unit

ProvisionDeploySmoke

Functional

Provision

DeploySmoke

Functional


Functional


Functional

Submit

Change

Does thiscode changelook good?

Do we wantto ship this?

What We Learned From the Market

Configurable Pipelines• Plug in your preferred or required subsystems for testing, provisioning

test nodes, building and publishing artifacts Don’t test Java applications with the same tools that test .NET applications Might run your QA environment in-house or in a cloud

• Middle environments might be long-lived (good for integration among several projects) or short-lived (better for smoke testing a single project)

Pipelines with Portability• The pipeline skeleton layout should be easy to bring to any new

project• Predictable stages and steps allows teams to choose correct tools for

each checkpoint• Developers and Testers don’t have to learn multiple different

workflows to work on different projects

Simple Entry Points• All change – application or infrastructure – has the same entry point• Code is the starting point!

Team members can use their preferred tools to create the code• Check code in, kick off the pipeline• Include peer review for all changes early

Human Gates• A lot of the work in your pipeline should be automated and not require

human interference as long as nothing breaks• Peer review at the first stages of the workflow can catch errors,

incorrect assumptions, potential security issues before more work is done

• When the tests pass, do you want to ship the change? Conditions may have changed since the code was first checked in Assess risk, make final product decision, provide approval

• May not be necessary for every change

Maintaining Believable Testing Environments• Do they even look a little bit like production?• System automation plays a big role in minimizing the impact of having

more test hosts• Cloud management, provisioning tools allow for more granular spin up

/ turn down for hosts that aren’t used all the time Profiles can be permanent / long-lived, but the hosts don’t need to be

The stages are fixed, and each stage has a fixed set of phases


LintSyntax


LintSyntax

Unit


Functional

Provision

DeploySmoke

Functional


Functional


Functional

Submit

Change



Your Workflow Reflects Your Culture• Are you Lean? Your workflow will be Lean• Are you Agile? Your workflow will have multiple points of agility• Is your environment regulated, held to compliance guidelines? Your

workflow should include those requirements

Wait, what?You put the security stuff in the pipeline?

Product Ideas and Features

Security Review

Production

Wow• Keeping your pipeline in a predictable shape aids in transparency and

knowledge sharing• The inclusion of additional “non-functional” requirements becomes

less onerousBUILD

LintSyntax


Security scan is in the BUILD step. Before the change goes into more expensive or time consuming testing processes

InSpec• Rspec-like language to verify security settings and compliance in your

systemsSSH supports two different protocol

versions. The original version, SSHv1, was

subject to a number of security issues. Please use SSHv2 instead to

avoid these.

describe sshd_config do impact 1.0

title 'SSH Version 2'

desc <<-EOF SSH supports two different... EOF

its('Protocol') { should cmp 2 }end

Review Unified Pipeline ShapeThe stages are fixed, and each stage has a fixed set of phases


LintSyntax


LintSyntax

Unit


Functional

Provision

DeploySmoke

Functional


Functional


Functional

Submit

Change



Shared Workflow for Strong Integration TestingDelivery’s pipeline is shared across projects and teams

Chef’s Automate Pipeline• Builds on the flexibility of the original Chef project – System

Automation• Includes peer review right out of the box• Encourages building robust testing by locking in stages and phases

while allowing configurable steps via code• Deploys right to production, because Chef knows about your

infrastructure already

To Learn More• https://chef.io• Visit our Booth: GG6• https://continuousdelivery.com more on Continuous Delivery in

general from Jez Humble

https://chef.io/

https://continuousdelivery.com/

Visit Us At Our Booth, #GG6

Technology

Role of Pipelines in Continuous Delivery