Role of Pipelines in Continuous Delivery
•Download as PPTX, PDF•
0 likes•321 views
My talk from IPExpo Europe, October 6, 2016
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Role of Pipelines in Continuous Delivery
Similar to Role of Pipelines in Continuous Delivery (20)
More from Mandi Walls
More from Mandi Walls (20)
Recently uploaded
Recently uploaded (20)
Role of Pipelines in Continuous Delivery
- 1. The Role of Pipelines in Continuous DeliveryMandi Walls | Technical Community Manager, EMEA | mandi@chef.io
- 2. Hi! • Mandi Walls • Technical Community Manager for EMEA • @LNXCHK • mandi@chef.io
- 3. Let’s Talk About Pipelines
- 4. 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
- 5. 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
- 6. 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
- 7. 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
- 8. 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
- 9. 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
- 10. The stages are fixed, and each stage has a fixed set of phases APPROVE DELIVER Lint Syntax Unit Security Quality Publish Lint Syntax Unit Provision Deploy Smoke Functional Provision Deploy Smoke Functiona l Provision Deploy Smoke Functional Provision Deploy Smoke Functional Submi t Chang e Does this code change look good? Do we want to ship this? What We Learned From the Market
- 11. 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)
- 12. 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
- 13. 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
- 14. 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
- 15. 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
- 16. The stages are fixed, and each stage has a fixed set of phases APPROVE DELIVER Lint Syntax Unit Security Quality Publish Lint Syntax Unit Provision Deploy Smoke Functional Provision Deploy Smoke Functiona l Provision Deploy Smoke Functional Provision Deploy Smoke Functional Submi t Chang e Does this code change look good? Do we want to ship this?
- 17. 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
- 18. Wait, what? You put the security stuff in the pipeline?
- 19. Product Ideas and Features Security Review Production
- 20. Wow • Keeping your pipeline in a predictable shape aids in transparency and knowledge sharing • The inclusion of additional “non-functional” requirements becomes less onerous Lint Syntax Unit Security Quality Publish Security scan is in the BUILD step. Before the change goes into more expensive or time consuming testing processes
- 21. InSpec • Rspec-like language to verify security settings and compliance in your systems SSH 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
- 23. Review Unified Pipeline Shape The stages are fixed, and each stage has a fixed set of phases APPROVE DELIVER Lint Syntax Unit Security Quality Publish Lint Syntax Unit Provision Deploy Smoke Functional Provision Deploy Smoke Functiona l Provision Deploy Smoke Functional Provision Deploy Smoke Functional Submi t Chang e Does this code change look good? Do we want to ship this?
- 24. Shared Workflow for Strong Integration Testing Delivery’s pipeline is shared across projects and teams
- 25. 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
- 26. To Learn More • https://chef.io • Visit our Booth: GG6 • https://continuousdelivery.com more on Continuous Delivery in general from Jez Humble
- 27. Visit Us At Our Booth, #GG6
Editor's Notes
- We’ve taken a different approach compared to other solutions in that in Delivery the pipeline has a fixed shape. Pipelines consist of six fixed stages, each of which is comprised of a fixed set of phases. It's not that we're trying to be inflexible; change the conversation. The common pipeline is prescriptive because it's based on our collective experience. The flexibility resides in the way you define what happens in each phase, described in the next two slides. An example here is you can include compliance in your workflow via the Functional phase to confirm that your organization’s security rules are part of testing a change Part of the reason this is the right approach is that arguing over the pipeline shape can become a huge delay to adopting CD. Custom pipelines are more difficult to maintain and keep stable over time. Delivery includes explicit review and approval gates This allows you to manage change in a way that is compliant with your business or regulatory requirements
- We’ve taken a different approach compared to other solutions in that in Delivery the pipeline has a fixed shape. Pipelines consist of six fixed stages, each of which is comprised of a fixed set of phases. It's not that we're trying to be inflexible; change the conversation. The common pipeline is prescriptive because it's based on our collective experience. The flexibility resides in the way you define what happens in each phase, described in the next two slides. An example here is you can include compliance in your workflow via the Functional phase to confirm that your organization’s security rules are part of testing a change Part of the reason this is the right approach is that arguing over the pipeline shape can become a huge delay to adopting CD. Custom pipelines are more difficult to maintain and keep stable over time. Delivery includes explicit review and approval gates This allows you to manage change in a way that is compliant with your business or regulatory requirements
- This is how I think of “security reviews” – they slow down the flow and change backs up. The more changes back up, the more we need to “expedite” or “force” things through the dam in order to satisfy LoB needs. Which leads to…
- We’ve taken a different approach compared to other solutions in that in Delivery the pipeline has a fixed shape. Pipelines consist of six fixed stages, each of which is comprised of a fixed set of phases. It's not that we're trying to be inflexible; change the conversation. The common pipeline is prescriptive because it's based on our collective experience. The flexibility resides in the way you define what happens in each phase, described in the next two slides. An example here is you can include compliance in your workflow via the Functional phase to confirm that your organization’s security rules are part of testing a change Part of the reason this is the right approach is that arguing over the pipeline shape can become a huge delay to adopting CD. Custom pipelines are more difficult to maintain and keep stable over time. Delivery includes explicit review and approval gates This allows you to manage change in a way that is compliant with your business or regulatory requirements
- Delivery behaves no differently for "infrastructure" code or "application" code. One of our core principles is that code is code, and Union is where all the pieces meet. - To weave compliance in here, you can talk about using the pipeline to quickly delivery patches needed in an emergency remediation scenario (vulnerability response) An update for compliance is likely something that should be managed via a cookbook, such as OpenSSL patch to remediate a vulnerability Each project has its own acceptance pipeline. The system enforces a single change-at-a-time moving through each of Union, Rehearsal, and Delivered. This keeps things stable. If something breaks, you can identify the change that introduced the breakage, and you know who to pull into a conversation about how to fix things. NOTE: the psychology of what are you making a change to? The WHOLE THING. It's a system. Not a project. This is a good place to talk about why the shared pipeline model promotes safety: Delivery promotes a “small batch” model, shipping one thing at a time to ensure discovery of integration problems before a change reaches production. Union is the place where all the pieces meet within a dependency set to ensure the system as a whole is safe. If you are managing 4 projects through your Delivery pipeline and the first 3 have dependencies within each other, we can think of those as a conceptual dependency set within Union. If the fourth project that is not part of that dependency set has a change that needs to go through, it will not get “stuck” behind changes related to the first 3 projects. In this way it is possible for changes to move through the shared pipeline in parallel, where there are not overlaps in their respective dependencies. Being able to move fast itself adds safety: remediation of defects, vulnerabilities etc. Systems that are easy to fix are safer. Q. Why did we not choose "QA", "staging" and "production" as the names instead of "union", "rehearsal", and "delivered"? And can I customize the names? A. The semantics of those words are overloaded and different in each business, so we wanted to start from a clean slate. The names cannot be changed.