The DevOps Behind the First Student ID in Apple Wallet

A Nine-Month Window and a Partner Willing to Walk Away

For years, the campus card business at Blackboard, the unit that later became Transact Campus, had been preparing for the day a student ID could live on a phone. It seeded campuses with NFC readers long before the phone makers were ready for the idea. "We had this vision well before the rest of the market did," recalls Taran Lent, who led product development. When Apple was finally ready, the opportunity arrived with conditions attached.

Apple wanted to announce student IDs in Wallet at its Worldwide Developers Conference in June 2018, and it set hard milestones on the way there. The team was told plainly that if those milestones were missed, Apple was prepared to cancel the project and move on to other opportunities. That left roughly nine months for work that, by the client's own estimate, deserved far longer. As Lent put it, working with Apple will "either make you or break you. Not everybody can keep up with them."

The stakes were not abstract. A student ID is not a loyalty card. It opens residence hall doors, pays for meals and laundry, and checks students into labs and libraries. A credential that fails on launch day locks real people out of real buildings, on the campuses of three major universities, with Apple watching.

Lower Environments That Had to Behave Like Production

The hardest requirement was not a feature. Apple surrounded the project with its own QA and testing teams, working around the clock from several regions of the world. That meant the development and test environments, the ones most engineering organizations treat as disposable, had to be as robust as production and had to stay up at all hours. The team leading the program had never operated lower environments that way on any prior project.

That is the problem we were brought in to solve. We joined the Mobile Credential program in 2018 to lead cloud-native DevOps, and the brief was velocity without fragility: let the product teams ship continuously, keep every environment trustworthy for Apple's testers, and remove the manual steps that make a release a gamble.

• Automated build and release pipelines. Releases that once took twenty manual actions became one. Lent's summary: "You push 20 buttons to get something done. Let us make that easier, you push one button."
• Always-on environments for every audience. Separate, continuously available environments for the internal development teams and for Apple's QA, each operated to production standards.
• A cloud-native foundation on Azure. Message queue services and containerized compute, deployed across East and West regions for high availability, with automated scaling and failover.
• Automated deployment and certificate management. The error-prone work of rotating credentials and promoting builds moved out of people's hands and into the pipeline.
• Training alongside the tooling. We taught the client's engineers the new tools and practices as we introduced them, so the capability stayed after the launch.

"If we didn't have that automation in place," Lent said afterward, "it would have been really difficult to hit those dates."

Three Days in October

Apple announced contactless student IDs at its developer conference in June 2018. On October 2, 2018, the feature went live for students at Duke University, the University of Alabama and the University of Oklahoma. The rollout ran over three days, coordinated through an all-day conference call with Apple while each university joined to complete its side of the launch.

At the end of that week, Apple shared an observation with the team. Every comparable partner launch, including major banks putting their credit cards into Wallet, had hit some technical event that paused or interrupted the rollout. This one had not. It was the only partner launch to that point that ran without such an interruption, and the team's decisions about automation were named as a reason.

The company had become, in Lent's words, "the first company in the world to issue digital keys to Apple phones and watches that could be used to unlock doors and perform access transactions on a college campus."

What the Platform Became

A launch is a moment. The platform underneath it has to keep working long after the press release. The cloud-native foundation built for Mobile Credential went on to support more than a million credential provisions, with integration points for Apple Pay, Google Wallet and Samsung Pay. When the campus business separated from Blackboard and became Transact Campus, the platform kept serving universities through the transition.

The way of working outlasted the project too. Lent described the change as going "from zero to really rapid development and deployment of our solutions," and said the engagement helped the teams become "very mature and very modern with our approach very quickly." We continued with Transact Campus for years afterward, which is a story of its own: read the Transact Campus story.

When You Need This, and When You Do Not

Most software teams do not need environments that run like production at three in the morning, and we will say so if you ask. If you release a few times a month, test with your own people during business hours, and can tolerate an afternoon of downtime in staging, a simpler pipeline will serve you better and cost far less to run.

The calculation changes when someone outside your company depends on your lower environments. That might be a platform partner certifying your integration, an auditor sampling evidence, a customer running acceptance tests, or a regulator with a fixed date. In those situations your test environments are part of the product, and an unreliable one costs you the relationship, not just a day. The same is true when a launch date belongs to someone else and cannot move.

If that sounds like your next twelve months, the useful first step is a conversation about where your delivery process would break under that pressure. That is usually visible in an hour, and fixing it early is far cheaper than discovering it in front of a partner.