Automating Releases Into Azure for a Campus Technology Leader
Service Fabric, Octopus Deploy, Jenkins and Terraform, turned into a release process any team could use.
When the Release Is the Bottleneck
In 2018 the campus card business at Blackboard, the unit that later became Transact Campus, was building faster than it could ship. Its services ran in Azure on Service Fabric, a capable platform with an unforgiving learning curve, and getting a change from a developer's machine to a running cluster involved scripts, hand-managed variables and a good deal of institutional memory. That was survivable for a steady product. It was not survivable for what was coming: a mobile credential program with Apple's deadlines attached, and a growing set of shared services that every product depended on.
We were brought in to lead cloud-native DevOps for that organization: to automate how its software was built and released into Azure, and to make the process something any team could use without a specialist standing beside them.
Release Automation, Piece by Piece
The work was less a single system than a set of building blocks that, together, turned releases from a craft into a routine. Each block was designed to be reused by the next team that needed it.
Building Blocks
-
Provisioning as code
-
Terraform definitions and hardened PowerShell scripts for creating Azure resources, replacing one-off setup with repeatable, reviewable infrastructure. A Terraform and Octopus Deploy pipeline tied provisioning to release.
-
Deployment step templates
-
Reusable Octopus Deploy steps for the things every service needed: Key Vault secrets, load balancers, Redis, virtual machine scale set extensions, variable sets. A new service assembled its release from these instead of writing its own.
-
Service Fabric, made routine
-
Cluster creation, placement constraints, fault and upgrade domains and full releases across all microservices were worked through, documented and automated, so the platform's depth stopped being an obstacle.
-
Certificate rollover runbooks
-
Expiring certificates are how reliable systems fail on a quiet weekend. Runbooks automated the rollover for the clusters so it became a scheduled task rather than an emergency.
-
Continuous integration
-
Jenkins pipelines and an Octopus test environment gave every change a path through build and verification before it could reach a release, and gave the QA process something consistent to work against.
-
Modular shared infrastructure
-
The shared services that several products relied on were rebuilt as modular infrastructure with the same templates, so the platform teams and the product teams were finally speaking the same language.
The Proving Ground
The mobile credential program was where this automation earned its keep. Apple's own testers needed lower environments that behaved like production, around the clock, and the team had nine months to deliver. The release machinery built here is what let the product teams ship continuously and let the environments stay trustworthy under that scrutiny. That launch, and Apple's verdict on it, is its own story: the first student ID in Apple Wallet.
Taran Lent, who led product development for the campus business through those years, put it plainly: "What UDX did is they came in and they created automation. They helped us learn new tools. They educated and trained our teams on some of these new practices that were new to our teams."
"
What Carried Over
In 2020 the campus business was divested from Blackboard and became Transact Campus. Everything built in this period went with it: the templates, the pipelines, the runbooks and, more importantly, the habit of treating the release process as engineering rather than ceremony. When the new company asked us to become its embedded DevOps team later that year, the foundation was already there. That engagement ran for another four and a half years.
When You Need This, and When You Do Not
If your services deploy with one command and a new engineer can release on their first week, you do not need release automation work; you need to protect what you have. The teams that do need it usually recognize themselves in one of three situations: releases depend on a person, environments are configured by hand and quietly diverge, or a deadline from outside the company is about to expose both.
The useful first step is not a tool decision. It is an honest map of how a change gets to production today, with every manual step and every person it depends on marked. That map is usually short to draw and uncomfortable to read, and it tells you exactly where to start.
Array
Where this work led, and the practice behind it.
The First Student ID in Apple Wallet
The launch this release machinery made possible.
Four and a half years as the embedded DevOps team after the divestiture.
The practice that stands behind every engagement like this one.
The delivery platform we run for clients today: one path to production, with evidence built in.
SOC 2, PCI, StateRAMP, FedRAMP and the engineering that keeps you certified.
Practical writing from our engineering practice on delivery, security and compliance.
Does Your Release Depend on a Person?
Tell us how a change reaches production today. We will map the manual steps with you and tell you which ones are worth automating first.