role of pipelines in continuous delivery
TRANSCRIPT
The Role of Pipelines in Continuous DeliveryMandi Walls | Technical Community Manager, EMEA |
Hi!• Mandi Walls• Technical Community Manager for EMEA• @LNXCHK• [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
ProvisionDeploySmoke
Functional
ProvisionDeploySmoke
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
VERIFY BUILD ACCEPTANCE REHEARSAL DELIVEREDUNIONAPPROVE DELIVER
LintSyntax
UnitSecurityQualityPublish
LintSyntax
Unit
ProvisionDeploySmoke
Functional
Provision
DeploySmoke
Functional
ProvisionDeploySmoke
Functional
ProvisionDeploySmoke
Functional
Submit
Change
Does thiscode changelook good?
Do we wantto ship this?
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
UnitSecurityQualityPublish
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
VERIFY BUILD ACCEPTANCE REHEARSAL DELIVEREDUNIONAPPROVE DELIVER
LintSyntax
UnitSecurityQualityPublish
LintSyntax
Unit
ProvisionDeploySmoke
Functional
Provision
DeploySmoke
Functional
ProvisionDeploySmoke
Functional
ProvisionDeploySmoke
Functional
Submit
Change
Does thiscode changelook good?
Do we wantto ship this?
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
Visit Us At Our Booth, #GG6