Brooke Treadgold – Back to Basics
- Transformation Lead ANZ Bank
- Not originally from a Tech background
- 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
- Risk Management
- 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
- First pipeline replace just one document
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.
- Docker has library of health check scripts
- Bunch of sample scripts for batect
- github.com/charleskorn/batect
