At its best, grocery shopping is fast and convenient: get what you need and get out. It’s easy to breeze through your local store or scroll through an app and miss the complex systems that get your grocery list from distributors to store shelves to your home. But behind your go-to pantry items is a vast network of code working to meet your needs. Today, the best grocers embrace technology, helping people search and shop faster than ever, even from home.

International food retailer Ahold Delhaize is no exception. Altogether, they operate 7,000 stores worldwide, serving 54 million customers every week through chains like Giant, Stop&Shop, Gall&Gall, and Albert Heijn. Though they started almost 150 years ago, the fastest growing part of their business is their e-commerce site, helping millions of customers eat well and shop anytime, anywhere.

At the heart of this experience is software, built by a team of more than 4,000 developers globally. As the head of Tech Enabling, Joost Hofman spends his weekdays on the hidden technologies providing every customer with a seamless retail experience. “A lot of people don’t realize how much innovative technology we’re using within a grocery store,” he added, “from smart labels in the stores that automatically update prices to fully personalized digital shopping experiences.”

Customers might have a cohesive experience with each of Ahold Delhaize’s brands. But internally, legacy tools and organizational divisions were slowing the IT organization down. Erik Roozeboom, Director of Integration Strategy and Architecture, described his team as forward thinking and agile. However, older companies can sometimes carry bigger legacies, he explained, including old applications, data centers, and more. “We try to do everything as we’d want to in the 21st century,” he said. “But we weren’t born in the cloud. A lot of IT functions are supporting old applications and traditional IT operations.”

To make matters more complex, Ahold Delhaize brands operate autonomously and set their own IT strategies. Even within many of these subsidiaries, engineers do not use a standard toolset or methodology. In practice, this unfurls into a vast ecosystem of technologies, applications, and ways of working.

Ahold Delhaize’s move to modernize and consolidate all of their systems started in 2019 with a short email from the head of the data science team: “Can we please have one repository?” This handful of words triggered a series of discussions and one conclusion. “We thought, ‘Well, maybe that’s a good idea,’” recounted Roozeboom.

At the time the email circulated, Ahold Delhaize managed code in a few ways. They were mostly using Bitbucket. “But then everybody had their own Bitbucket,” Roozeboom added. “And some people chose not to use a source code repository at all—instead storing code on their laptops and all over the place.” And while many teams used Jenkins and Bitbucket, more agile groups that had to deploy and manage applications themselves found it difficult to scale in terms of performance or peak demands. One tool couldn’t possibly be everything for everyone.

The pain points of this setup spurred Ahold Delhaize to find a better solution, and also look into answers to bigger problems, like “why is it so difficult to share?” As an enterprise architect, Roozeboom had been involved in projects across the organization. “I always see teams building things from scratch,” he explained. “Even though I know two or three other groups building the same exact thing.”

At first, coordinating code reuse and collaboration looks messy. Everyone is on separate timelines. They have separate budgets. It’s not as simple as sending a group message with a head’s up that a team in a different time zone is working on the same thing. Ahold Delhaize quickly found themselves not only choosing new tools but rethinking their engineering culture. They weren’t just finding a version control system, but a platform to enable a new level of collaboration.

Hofman was tasked with interviewing technical leads and recommending a platform. When evaluating tools, he was looking for ways to speed up development, deliver software to customers faster, and ensure code quality is up to their standards. For him, all of these were top of mind, but none more important than satisfied engineers. “We wanted to give them tooling that makes them happy, that helps them do their work without any hassle, and focus on what they like best: engineering.”

Hofman added that GitHub stood out for many reasons, but most convincing was the overwhelming preference for it. “It was the top request from our engineers,” he said. They wanted to branch out, build bots, and automate the more repetitive manual tasks—things they just couldn’t do with Bitbucket. And beyond features and functionality, he found open source at the heart of the team’s decision making. “The open source community lives on GitHub, and many of our engineers are part of it. It was just the most natural way to move forward.”

The team also chose GitHub for the flexibility it allowed them. Offerings like GitHub Actions and Packages had the potential to lower the number of hours spent maintaining Jenkins and a package store. As Lead Release Engineer Reinier Timmer described, “We needed to be more elastic, more current. Many people already use GitHub. Its huge community makes you feel like you’re working in the now, not on an old, heavily customized system.”

Timmer has seen immediate benefits in release engineering, where they’re focused on improving the reliability and philosophy behind their systems. “GitHub Actions and Packages have helped us meet our goals of increased reliability and velocity quite brilliantly,” he said.

GitHub Actions and Packages have helped us meet our goals of increased reliability and velocity quite brilliantly

For instance, now that the team migrated all of their JavaScript projects to GitHub, the packages are no longer part of a big, centralized system. “GitHub Packages puts packages where they belong,” said Timmer, “Close to the developers, who now have the flexibility to manage their own packages. ” Ahold Delhaize has threaded in automation with GitHub Actions to help lower the burden of maintenance.

“This way, developers can use packages for all releases, but we can also automatically clean them up as soon as we don’t need them anymore,” Timmer explained, “Before, we had lots of packages and artifacts that were never cleaned up. Now we can just use an Action for that. It’s very fun to automate these things, and the GitHub API helps a lot.”

Actions have also helped the team speed up delivery. Their self-hosted Jenkins CI system had a limited capacity that ultimately affected performance. At peak times, developers had to do a lot of sitting and waiting for their builds to start. But using Actions for CI/CD on the GitHub hosted runners, they can test code on multiple operating systems and platforms simultaneously, while also being able to scale to demand. Everyone can build their software directly without sitting in a queue.

“Everything we build now—our React components, etc.—are all run in Kubernetes and are all 100% automated,” Hofman added. “Essentially, for every pull request that’s opened and merged into the main branch, CI triggers a workflow. And from there to QA, deployment, and production, it’s completely automated.”

The team uses a few pre-built Actions, but when they can’t find what they need on GitHub or GitHub Marketplace, they build their own. If Ahold Delhaize developers make a useful improvement or create a new generic workflow, they’re inclined to share it. So far, they’ve built eight Actions, and are thinking about which ones to open source. “It’s a very fun, rewarding process,” said Timmer, “You’re helping build software that many others can benefit from and contribute to.” The team has already ventured in open-source territory by assisting in the development of an open-source solution for self-hosted runners on Kubernetes.

For Ahold Delhaize, the next step is making the most out of all of their code internally. “We’re currently onboarding the whole organization in order to build an inner source culture, from the US, to Europe, to Asia,” said Hofman. He recognizes that, while not all parts of the company are ready to open source their work, everyone can benefit from inner source.

The immediate goal for inner source is making sure that anyone in the organization can contribute to projects built elsewhere in the organization. Collaborating internally on pieces like Actions can make delivery faster, even as the team evolves. Ahold Delhaize understands that they can’t orchestrate a culture shift overnight. It needs time to seed and grow. Hofman said, “If we give people the right tools and the right platform, it’s a start. We can share more within our company and with each other, growing as an inner source organization and, maybe in the end, an open source one.”

Ultimately, Ahold Delhaize considers GitHub as an important part of their journey to show the world that retailers are now tech companies and to be a company where engineers are doing work that fulfills and challenges them. Hofman put it simply: “When the engineers are happy, I am, too.”