Source: itnews.com.au. Original reporting attributed to ITNews Australia, based on a presentation at Salesforce Dreamforce 19.
The Challenge: A Platform That Outgrew Its DevOps Team
When Qantas first deployed Salesforce as its CRM platform roughly five years before 2019, it stood up a small DevOps team to manage the environment. Over time, the platform grew significantly — from 430 users to over 1,400 — but the team size and processes remained largely unchanged. The airline runs two Salesforce “orgs”: one covering Qantas, frequent flyer, and freight operations, and a second for Jetstar.
Qantas CRM technical product owner Zain Ansari described the situation plainly at Salesforce’s Dreamforce 19 conference: “Our DevOps team was operating at the same capacity as when we first implemented the Salesforce platform, but the platform had almost doubled in size.”
With multiple project teams working in parallel on the same platform, visibility became a serious problem. Changes made by one team were often unknown to others until late in the release cycle, creating conflicts that were only discovered at the last minute.
Symptoms: Gatekeeping, Late Nights, and One Project at a Time
The DevOps team effectively became deployment gatekeepers — manually prioritising which code changes could go out, scanning code line by line for conflicts, and running tests on local machines before promoting anything to production. CRM platform owner Mark Pieterson described how the team’s balance shifted dramatically:
“At one stage we were a balanced DevOps team when there was only one project working. Then we became very, very Ops focused and we were just keeping the platform going.”
Mark Pieterson, CRM Platform Owner, Qantas
To reduce deployment risk, the team imposed a self-imposed rule: only one project could be deployed per release cycle. That constraint caused delays to stack up across multiple project teams waiting in a queue.
Deployments themselves were punishing. Because of business sensitivity around downtime, the team could not begin deployments until after business hours. Pieterson recalled engineers regularly working past midnight — then returning the next morning to handle post-deployment follow-ups. Deployments ran 8 to 10 hours and occurred roughly every fortnight.
“Every deployment felt like a mini-project. It was all hands on deck.”
Mark Pieterson, CRM Platform Owner, Qantas
The Solution: AutoRABIT for Salesforce CI/CD
Qantas selected AutoRABIT, a DevOps and CI/CD platform purpose-built for Salesforce environments, to address both the technical and cultural dimensions of the problem. AutoRABIT provides tooling for version control, automated deployments, CI job pipelines, and conflict detection across Salesforce orgs.
Ansari outlined the immediate practical gains the platform delivered:
- Earlier conflict detection: Code clashes that previously surfaced hours before deployment were now identified days in advance, giving teams time to resolve them without crisis-mode scrambling.
- Auditability and transparency: The team gained clear visibility into exactly what was going into production and when, across all concurrent project teams.
- Faster deployments: Deployment windows shrank from 8–10 hours every fortnight to 2–3 hours, with the lengthier windows becoming the exception rather than the norm.
- Reduced manual effort: CI jobs automated steps that previously required engineers to manually handle code movement between environments.
“The AutoRABIT platform gave us some features and a framework to start introducing some CI/CD processes or some best practices, and more automation than what we had in the past.”
Zain Ansari, CRM Technical Product Owner, Qantas
Cultural Change as Much as Technical Change
Pieterson was emphatic that the AutoRABIT initiative was not simply a tooling project. The team had a deliberate goal of shifting mindset and improving working conditions — what he described in terms of “quality of life” for the DevOps engineers.
“The quality of life subject for us is very important. It’s embedded in the Qantas DNA to look after our people.”
Mark Pieterson, CRM Platform Owner, Qantas
Eliminating routine midnight deployments had a measurable impact on morale and sustainability. As automation absorbed the repetitive operational load, engineers were freed to do more development work, platform enhancement, and strategic Salesforce ecosystem projects — the higher-value work the team had been hired to do in the first place.
Measuring DevOps Maturity
Throughout 2019, Qantas used a DevOps maturity benchmarking methodology associated with AutoRABIT to track progress and identify the next areas for improvement. The airline treated automation adoption as an incremental journey rather than a one-time implementation.
Ansari described the ongoing direction clearly: “We want to do things more efficiently: continue to automate more, and do more things through CI jobs so that we can free our people up.”
Team Growth: First Resourcing Change Since 2015
One concrete outcome of demonstrating the value of improved DevOps practice was organisational: Pieterson received approval to grow the team for the first time since the Salesforce platform was originally stood up around 2014–2015. As the platform continues to expand inside Qantas and Jetstar, increased headcount combined with better tooling is intended to ensure the team can scale without repeating the same bottlenecks.
Key Takeaways for Salesforce DevOps Teams
- Salesforce-specific CI/CD tooling matters. General-purpose pipelines may not handle Salesforce metadata, org dependencies, and deployment mechanics well. Purpose-built tools like AutoRABIT are designed to address these constraints directly.
- Conflict detection earlier in the pipeline saves deployment-day pain. Shifting conflict discovery from deployment night to days in advance is one of the highest-leverage improvements a Salesforce DevOps team can make.
- Ops overload is a leading indicator of team burnout. When a DevOps team becomes purely operational, the engineering talent that justifies the team’s existence stops being used. Automation is the lever that rebalances this.
- Cultural goals need to be explicit. Framing automation investment in terms of team quality of life — not just throughput metrics — makes change initiatives easier to sustain and champion internally.
- DevOps maturity is a journey, not a project. Qantas spent the bulk of 2019 incrementally expanding automation capabilities, treating the initial AutoRABIT deployment as a foundation rather than a finish line.