Making cd happen thought works talks tech 27 march 2019

Making Continuous Delivery
happen
Sriram “Ram” Narayanan
ThoughtWorker
Twitter: @sriramnrn
www.sriramnarayanan.com
Presented at ThoughtWorks Talks Tech - 27th March 2019

Workshop
Making Continuous Delivery happen
Upcoming workshop: April 2019
Contact sriramnrn@gmail.com to indicate your interest
Book publication date: 30th April 2019

@sriramnrn
Agenda
The current state of “CI/CD”
Failure to deliver
Understanding CD
Making CD happen

@sriramnrn
The current state of “CI/CD”
General Direction: We have to be Agile and we need “CI/CD”
The current state of “CI/CD”:
- Install a CI system
- Create a few jobs to build components, deploy apps, run tests
- Install all manner of integrations and plugins
- Trigger a “Prod Deployment” Job in the CI
- Mandate the same structure all across the org for every project
- Declare you have “CI/CD” in place

@sriramnrn
- DevOps means writing Unit tests
- DevSecOps means having a CI/CD server with security scanners like Fortify
- “CI/CD” requires Microservices on Kubernetes
Other statements that we’ve encountered

@sriramnrn
- There are still defects in production
- Lots of time between code commit to go-live
- Triaging defects continues to take time
- Integration between workstreams continues to be risky
- Fixing a defect doesn’t guarantee that nothing else got broken
- Changes pushed to prod often leads to failures
- What works in one environment doesn’t work in others
And yet….

@sriramnrn
Current “CI/CD” implementations - Reality check
What business thinks they’ve funded What business actually gets
“Continuous Integration and Continuous
Delivery/Deployment”
Expensive Tools and Scrum
Implementations
“Zero Defects” Reports
Fast turn-around times New ways of achieving the same old delays
- There are still defects in production
- Lots of time between code-commit to go-live
- Triaging defects continues to take time
- Integration between workstreams continues to be risky
- Fixing a defect doesn’t guarantee that nothing else got broken
- Changes pushed to prod often leads to failures
- What works in one environment doesn’t work in others

@sriramnrn
So what’s going on here?

@sriramnrn

@sriramnrn
- Continuous Deployments (actually, a business decision)
- Only Continuous Integration on some arbitrary branch
- Only Automated Deployment to Prod
- Only Compilation and Packaging (Zero thought given to deployments)
What Continuous Delivery is not

@sriramnrn
What
Ability to get software changes into production, or into the hands of users, safely and quickly in a sustainable way.
Decision to deliver is by a stakeholder group (often product management or business stakeholders)
Code is always in a deployable state (meets business acceptance criteria for deployment)
Why
○ Flexibility - working with smaller quicker releases allows for re-prioritization and change of direction
○ Higher Quality - automated process and keeping code in a deployable state encourages higher quality.
○ Smaller tasks/goals allow for better cost estimation and reduced deployment risk.
○ Shorter feedback cycle and faster response times
Continuous Delivery

@sriramnrn
Making Continuous Delivery happen
Optimise the Value Stream Map
Automated Gatekeeping checks

@sriramnrn
The Value Stream Map
Process Process Process Process
Wait
time
Process
time
Repeats

@sriramnrn
The Value Stream Map - what’s happening here
Process Process Process Process
Wait
time
Process
time
Repeats
Waiting on:
- Processes that are scheduled, not automated
- Infrastructure and dependencies that are shared
- Gatekeeping checks
Reasons for repetition:
- Misaligned dependencies
- Expectation mis-matches (e.g. failed
QA checks; security violations;
doesn’t work in an environment)

@sriramnrn
Delivering reliable code

@sriramnrn
On tests,
and documentation as tests

@sriramnrn
Branching approaches that we’ve seen
What we’ve seen Why they want it Risks
Branch per story What went into a story? Merge issues between stories
Branch per environment What went into an environment? Large integration sets between
environments
Branch per release (with
features and fixes being ported
across branches)
What went into a release? Porting back and forth,
release-specific variants of the
same features!

@sriramnrn
@sriramnrn

@sriramnrn
On automating gatekeeping
checks

@sriramnrn
Sources of Truth
Entity Source of truth
Business Requirements verified in the UAT environment
and delivered “defect free” in the PROD
environment
Business Analysts Stories verified at Desk check and the UAT
environment
Devs Stories verified locally
QA Stories verified in the QA environment
Security, Ops Secure SDLC, Pen Testing, Static Analysis
Conform to Prod settings

@sriramnrn
Sources of Truth - ensuring parity across them
Entity Source of truth Verification
Business Requirements verified in the
UAT environment and delivered
“defect free” in the PROD
environment
Requirements to workflows
Business Analysts Stories verified at Desk check
and the UAT environment
From workflows to stories (and
acceptance criteria for stories)
Devs Stories verified locally Automated tests that pass
QA Stories verified in the QA
environment
Verify that Acceptance criteria
have automated tests
Security, Ops Secure SDLC, Pen Testing,
Static Analysis
Verify that Acceptance criteria
have automated tests

@sriramnrn
Good health
- Sleep, exercise, nutrition, stress-management
- Do you say “jogging/good-health”?
Continuous Delivery
- More than just a CI tool and automated scans
- More than just Continuous Integration
The risk of saying “CI/CD”

www.thoughtworks.com
@sriramnrn
Thank you

Making cd happen thought works talks tech 27 march 2019

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Making cd happen thought works talks tech 27 march 2019

Semelhante a Making cd happen thought works talks tech 27 march 2019 (20)

Último

Último (20)

Making cd happen thought works talks tech 27 march 2019