Streamlining Go Microservice Releases: From Multi-Repo to Monorepo in a Flash

Introduction

Managing microservices can be challenging, especially when dealing with multiple repositories. Each service often exists in its silo, leading to delays during releases due to the manual effort involved in coordinating updates across these disparate codebases. Recently, I transitioned from a multi-repo structure to a monorepo for six Go microservices, and the results were astounding—releases became 15 times faster! In this article, I'll walk you through my process of automating these releases, highlighting the benefits of the monorepo setup.

The Challenges of Multi-Repo Management

In a typical multi-repo environment, each microservice tends to have its own repository. While this can initially appear advantageous due to clear separations of concern, it often leads to several issues:

These challenges prompted my move towards a monorepo setup, where all microservices reside under a single repository.

Transitioning to a Monorepo

Successfully transitioning to a monorepo requires careful planning and execution. Here are key steps I followed during the migration:

1. Repository Restructuring

First, I combined all six microservice repositories into a single monorepo. This involved:

To achieve this, I utilized the following Git command:

git remote add serviceA <url_of_serviceA_repo>
git fetch serviceA
git merge serviceA/master --allow-unrelated-histories

Repeat the above steps for all the services required.

2. Dependency Management

With all services under one roof, managing dependencies became simpler. The use of Go Modules proved essential for resolving versions. Each microservice specified its own dependencies in a go.mod file, which is crucial for builds. This also allows for using a single command to initiate builds for all services.

3. CI/CD Pipeline Automation

To realize the full benefits of the monorepo structure, I established a CI/CD pipeline that could automate the release process across all services. Using GitHub Actions as my CI tool, I created a workflow YAML file that encapsulated the build and deployment procedures. Here's a simplified version of my workflow script:

name: CI/CD Pipeline

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Build All Services
        run: |
          for dir in ./*; do
            if [ -d "$dir" ] && [ -f "$dir/go.mod" ]; then
              cd "$dir" && go build
              cd -
            fi
          done
      
      - name: Deploy
        run: |
          # Deployment command for each service
          echo "Deploying services..."

4. Improved Release Notes Generation

To facilitate smoother communication and documentation for the changes made, I implemented automated release notes generation using a tool like go-github-releaser, which compiles contributions and versions for all microservices in a single document. This helps stakeholders quickly grasp what has changed with each release.

5. Simplified Rollbacks

Finally, I recognized that the monorepo structure allows for easier rollbacks. If a particular release caused issues, I could revert all services back to their last stable state with a single command. This is a significant time-saver compared to individually reverting each service in a multi-repo setting.

The Results

With the transition complete, my team’s response to the centralized approach was overwhelmingly positive. The key results included:

Conclusion

The shift from a multi-repo to a monorepo approach for Go microservices has transformed how my team handles releases. Automation, improved management, and the ability to efficiently handle deployments and rollbacks culminate in a streamlined workflow that ultimately enhances productivity. If you are grappling with a similar multi-repo complexity,