Source Code Management is the first brick in ANZ’s Golden Path
by Jonny Oenning
In recent years the term Golden Path has been adopted in the technology industry to describe a way to build efficient software systems that standardise large parts of the assembly line and free up engineering capacity to focus it where it matters most.
For ANZ, having an efficient way to build software systems and minimise unnecessary costs will enable us to invest more in the community and better deliver on our purpose of shaping a world where people and communities thrive.
What is a Golden Path?
A Golden Path is a defined and supported path for building and deploying software. It is a way of standardising the software development process and reducing friction for developers.
What are the benefits of using a Golden Path?
There are many, and they include:
· Increased developer productivity: developers can focus on building features instead of worrying about the underlying platform and CICD pipeline.
· Improved quality: by following a standardised process, mistakes due to manual processing are less likely to occur.
· Reduced risk: a Golden Path can help to mitigate risk by ensuring software is built and deployed in a consistent and reliable way.
· Improved compliance: by enforcing policies without hindering innovation, you can meet risk obligations and uplift engineering practices.
In our engineering platforms team, we’re focused on making ANZ’s Golden Path consist of 8 pillars:
1. Source code management (SCM)
2. Continuous integration
3. On demand environments
4. Security and code analysis
5. Packaging and artifact storage
6. Security and library controls (supply chain)
7. Deployment
8. Feature release
Source code management
Having multiple SCM practices with disparate controls and policies is an anti-pattern to achieving an effective Golden Path. That’s why SCM is our first pillar.
Historically, as we have adopted new technologies and products for our SCM, we have left some old tech behind and not fully migrated away from it. To remediate this we adopted GitHub as our primary SCM a few years ago. We’ve been consolidating and migrating some of the old tech into it ever since.
Interestingly, even Cobol applications (our mainframe systems) are having a dose of modernisation with some about to finish their migration and cut-off to GitHub. Imagine that - Cobol with vscode + code insights! It’s fascinating how that alone is bringing new talent into the perceived ‘old’ stack.
Bringing all our code into a single repository has allowed us to really make a difference to how we manage our workflows and boost efficiencies. Here’s what we’ve done so far:
· Repository controls with config as code has allowed us to enforce policies relevant to us such as mapping code repositories to an application in production. Adding the application ID as a GitHub Topic makes the code traceable, validated, and searchable.
· With mandatory branch protection and code ownership, code reviews and code ownership have become mandatory by default.
· Inner source practices have created improved collaboration and less duplicity. Classifying repository visibility as ‘internal’ by default allows everyone to see and contribute to code. It also aligns code to code owners and branch protection policies.
· Repository hygiene factors such as a README file explaining a piece of code’s intent has improved code visibility, maintainability, and ownership.
SCM policy control services
The controls listed above are backed by a few GoLang services we’ve built that run on a Kubernetes cluster on our Google Cloud.
Aside from all the work on new repositories, we’ve also been uplifting the existing stuff (thousands and thousands of repos). We’re evolving these services to do a few cool things in a near feature drop:
· Raising pull requests for the owners of the repositories drifting away from policy
· Notifying code owners via Slack – our engineering workflow tools – of policy drifts
· Reporting on policy practices for the entire code base
To improve these practices and get better buy-in from the repo owners, we’re also ‘eating our own dogfood’ on inner sourcing and applying these same practices to the SCM policy control services. Every engineer in ANZ can contribute code, policies, and improvements to these sets of services.
What’s next?
There’s work happening on all the other pillars of our Golden Path. Some in pockets and some more advanced and in really good shape.
Engineering at ANZ is bringing all this together! By creating consistency, we’re getting closer to a vision where application services are standardised and a significantly large portion of the software delivery pipeline - from source code to canary deployment - is entirely automated by design.
This means creating a repository and having the initial templated service deployed in production - including the infrastructure - in minutes, in a single click. Or rather, as a single pull request.
Because of our work so far on a Golden Path, the present is a lot more interesting for a lot of our engineers. And the not-to-distant future is looking bright!
Jonny Oenning is an Engineering Continuous Delivery advocate at ANZ. He has been advocating for over a decade that efficient software delivery evolves around efficient CICD pipelines. He believes that achieving continuous delivery in the form of multiple deployments a day is the ‘game over’ holy grail that every application team should strive for. Jonny has been at ANZ for 7 years with previous experience in a variety of industries in DevOps / CICD / SRE – new terminology for an age-old problem – continuous delivery. He's proudly helping shape the future of engineering at ANZ.
This article contains general information only – it does not take into account your personal needs, financial circumstances and objectives, it does not constitute any offer or inducement to acquire products and services or is not an endorsement of any products and services. Any opinions or views expressed in the article may not necessarily be the opinions or views of the ANZ Group, and to the maximum extent permitted by law, the ANZ Group makes no representation and gives no warranty as to the accuracy, currency or completeness of any information contained.