Tech has a lot of buzzwords and acronyms that make it an exclusive club. Improvements relay on people from other parts of the business that aren’t in that club
These people have to care about it and understand it.
Had to use terms that everybody in the business understood and related to.
Case for change – What top orgs do:
208 times more frequent deployments
2604 times faster to recover from incidents
7 times lower change failure rate
What you need
High Priority -> Access to people to do the work
Needed tangible goal (weekly releases) to get people to focus (and pay)
Making change a reality
Risk Management
You can just stop doing the reports
You need to gain their trust in order to get influence
Have to take them along the way with the changes
Empathy
Influence
History at ANZ
First pipeline replace just one document
Explained to change managment team how the pipeline could replace the traditional plan
Rethink of Change Plan and Outcome Reports
Other teams needed these for confidence in the change
Found out what people actually cared about, found better ways to provide that information (confidence) it an automated way
Security Assessment
Traditionally required a big document filled in and signed off
Found that this was only required for “Significant” changes
Got a definition of what significant means so didn’t need to do this.
High Risk Change Records
Lots of paperwork for High Risk changes
Decided that these are not high risk changes so lots less work
Templated them so a lot easier to do
Charles Korn – Dockerised local build and testing environments made easy
Go Script – Single script that a consistence place in all you repos that does the basic function. install, help, run, deploy
batect – tool he wrote
dockerized dev environment plus a Go Script
Dev environment
Build env: code to an artifact
Testing Environments. Fake stuff, lots of different levels
Build Environment
Container with the build tools. Mount our code directory into this
Isolation brings consistency and repeatability. No more “works on my machine”
Clean container every single time we run a build
CI agents just need docker since teams will provide the container
Ease of Onboarding. Just get git and docker installed
Ease of change. Environment and tasks defined in yaml and versioned like everything else. New version downloaded. Kept in sync with actual code
Test Environments
You can run local tests
Consistently runs test on CI
Have to launch multiple containers for more complex tests, using built in docker definitions and health checks and networking
Path to Production
If deploying docker then can use same image
But works with stuff that isn’t deployed as docker too
What about docker compose?
Better performance
Model – tasks are a first class citizen – Doesn’t feel like you are fighting the too.
Better UI and developer experience. Updates managed automatically
Cleans up better after each run
It just works. Works with proxies better. Works with file permissions better.
How to get started?
start small, work incrementally
Start with the build enviroment
With the Test env work though one piece at a time.
Reuse components
Take advantage for other people’s images. Lots of mocks for cloud services.
