Deploying Code to Production on Day 1
By Sam Acharya, Technology Associate
Macquarie Bank is not just another bank. We operate as a technology company that delivers leading digital banking services and experiences to our customers in Australia. The aspirations for our Engineering teams are reflected through our “North Stars”, our goals that set our direction. One of these goals is to have all new starters shipping code to production on day 1 of being on board. I’m proud to say that we were able to achieve this North Star within the Robotics team at Macquarie Bank. In this post, I will walk through my experience of deploying code to production on my first day, why we think it’s important that all engineers should ship code to production on day 1 and the mechanisms we have in place to do so.
3…2…1… Done.
A green tick appeared on my screen indicating that my build was successful. I looked down at my watch. It was 3:52pm on my first day at Macquarie as a graduate within the Robotics team at Macquarie’s Banking and Financial Services (BFS) division. It was only four hours after I had received my laptop, and I had just pushed code into production. I couldn’t help but smile as I was overcome with a sense of accomplishment from having made an impact on my first day.
In the four hours since receiving my laptop, I was able to configure my applications, meet my team, go for lunch in picturesque Barangaroo, write a program and then deploy it into production. Although the program was not complicated, deploying it into a production environment on my first day was a testament to the fact that my team and Macquarie as an organisation had invested considerable time and effort into improving the development experience for engineers and forming robust CI/CD processes. These investments allowed me to deliver at speed with high levels of reliability, which ensures that we stay agile and competitive as an organisation.
The experience also indicated that many of my assumptions about working at Macquarie were incorrect. I was under the impression that working in a financial institution meant that the development process would be arduous and deploying into production would be filled with workflows that could take days to process. I also thought that being a graduate would mean that I could not touch the production environment for weeks, and would instead be coding in cordoned off developer environments.
Clearly, I was wrong.
Over my first 25 days at Macquarie Bank, I witnessed the depth and breadth of our technical capabilities and the speed of delivery that are enabling us to deliver leading digital banking experiences to our customers. I have also been lucky to be part of a huge team. Our Engineering team has over a thousand people from diverse backgrounds, united by our passion for technology. We have set big goals for ourselves — our ‘North Stars’ — that we would like to achieve by 2025. One of these goals is to have ‘All new starters shipping code to production on day 1.’ In my opinion this is one of the most important goals that we can set for ourselves.
Why should an engineer be able to deploy to production on day 1
Deploying to production for the first time is a rite of passage for any engineer joining a team. Upon deployment, you become a fully-fledged member of your team and leave your mark on the technological footprint of the business. It exposes you to an engineering culture that values collaboration and trust, and demonstrates that the work you do has a real impact on your customers.
Pushing to production involves numerous tasks that require collaboration between you and your team. During my deployment, I developed a program as a pair with my team buddy. I then asked our lead engineer to complete a code review to ensure that my code was error-free and applied best-practice principles. Finally, my manager checked my release Jira and plan to see if I had factored in the risks associated with deploying to production. He also ensured that I had a contingency plan in case things went awry. My release took a team of four to complete, and bigger releases within Macquarie can involve many more people.
Completing a release is also instrumental in building team rapport. We see a successful release as an achievement that is to be celebrated. Upon completing my release, my manager announced it to the rest of our team, and I received recognition from many of my colleagues. I had earned my stripes and was a fully-fledged member of the Robotics team.
Pushing to production also demonstrates the trust within your team and in your release management process. I felt trusted by my team, knowing that they could give me responsibility to make a real and lasting change to our organisation from the get-go. It greatly helped me in learning the deployment process. ‘Learning by doing’ greatly assists in helping you understand your release management process and builds muscle memory.
I could also see the trust we have in our CI/CD processes. Moving code across environments used to have a reputation for being cumbersome and time-consuming, but within our team it’s hassle free and only took a few minutes to complete. In fact, the BFS division alone completes on average an astounding 650–750 releases a month , with a further 7,000 releases per month happening across the whole Macquarie Group! The speed at which we operate showcases that we are truly an agile organisation that is able to release useful features to our customers or fix vital bugs ASAP.
How can engineers deploy code to production on their first day?
My team has numerous mechanisms in place to allow an engineer to deploy code on their first day.
- Providing a personalised new starter onboarding guide: We have a guide that outlines the onboarding process, which we personalise when an engineer joins our team to track their progress in real time.
- Gaining access to resources for a new engineer ahead of time, such as assigning them to Active Directory groups and providing access to applications.
- Designing a program that an engineer can develop and deploy to production on their first day.
Whilst these mechanisms are key, an engineer would not be able to deploy to production quickly and reliably without a well-defined release management process and a robust CI/CD pipeline.
A well-defined release management process
Having a well-defined release management process, as seen below, removes ambiguity and allows our team to focus on developing useful features for our customers or fixing bugs.
A Robust CI/CD pipeline
Having a robust CI/CD pipeline allows us to move code between environments quickly, safely and reliably. We use a combination of SS&C Blue Prism, BitBucket and Bamboo to deploy code between environments.
SS&C Blue Prism
SS&C Blue Prism (BP) is an automation platform we use to develop processes — the Robotics version of programs.
Any changes we make to a process within an environment (development, UAT or production) is stored within a BP database associated with the environment. If we want to deploy code, we form a ‘release package’, and then move it into the BP database associated with the deployment environment. Moving code manually to production poses a major risk and is time consuming. Instead, we version control using BitBucket and automate deployments using Bamboo.
Bitbucket
We use Bitbucket as a code repository and for branch management.
Development branch: During the development phase, we’ll create a new ‘development branch’ to push any code changes we make during the development phase. A development branch is created from a release branch. Engineers have read and write access to development branches, as they need to be able to commit code updates as they go.
Release branches: A release branch contains the code associated with a release that runs in production. After receiving approval to push into production, we create a pull request (PR) to merge changes from the development branch into the release branch. PRs need to be approved and the code merges are completed automatically using Bamboo as developers only have read access to release branches. We do this to ensure that any changes to production code are intentional and secure.
Bamboo
We use Bamboo as a CI/CD tool to conduct access checks for developers and to automate deployments between environments.
As soon as Bamboo detects a PR bring approved within Bitbucket, it first verifies whether the user that executed the pull request has write access to the branch. If the check is successful, it retrieves the code changes from Bitbucket, runs a series of automated tests and executes a script to write the merge to the BP database server associated with the environment we would like to deploy to.
What do we want to do next?
We have achieved one of our North Stars, and our investment in improvements continues. We would also like to:
- Allow developers their choice of device: We are aiming for all teams to have their choice of device, between a Windows PC or a Mac, with their own toolset and documentation.
- Role-based access process: We are streamlining the access process for resources by creating role-based access based for teams.
- Moving to BitBucket Pipelines: We are moving to Bitbucket Pipelines to further streamline our CI/CD process.
My takeaways
Deploying to production on my first day was a rewarding experience that will stick with me. The experience taught me that Macquarie Bank is different. We are an agile organisation that places emphasis on solid engineering principles and good technological outcomes. We value collaboration and trust, and effectively and efficiently maintain a focus on risk and compliance by investing in mechanisms to ensure that we can deliver robust and useful features to our customers at a rapid pace.
