Imagine a microservices application consisting of dozens of continuously-deployed autonomous services. Each of the application’s constellation of services has its own repository, with a different versioning scheme and a different team continually shipping new versions. In this article, we explore a couple different ways to manage microservices releases, including the common approach of one microservice, one repository, and managing microservices releases with monorepos. We also examine the steps needed to release an application organized into multirepos, including tagging the versions of microservices that will go into the release, building a Docker image for each microservice, testing the release candidate, compiling a list of changes for the release changelog, identifying hotfixes required for older releases, and publishing the release. Companies like Google, Airbnb, and Uber have been using the monorepo approach for managing their microservices, but whether you use multirepos or monorepos, successful release management for microservices ultimately depends on careful planning, testing, and documentation.
