What's your approach to managing multi-stage releases in a unified repository?

Other Questions Github
1

I’ve been working on streamlining our deployment workflow at my current company. We have multiple microservices that were previously scattered across separate repositories, which made coordinating releases really challenging for our release team.

We decided to consolidate everything into one repository with different folders for each service. This helped reduce the management overhead, but now we’re running into some new challenges with our three-stage release process (dev, staging, prod).

The main problems we’re facing:

  1. Selective deployments: We can’t easily deploy only the services that have actually changed. Every release triggers all services even if only one folder was modified.

  2. Stage promotion workflow: Moving releases from staging to production is clunky since we need to work with tags that aren’t recent commits anymore.

  3. Release approval process: There’s no built-in way to require code review for tag creation, which seems like a security risk.

I’m curious how other teams handle similar multi-stage release workflows. Are there better strategies or tools that make this process smoother? Any suggestions would be really helpful!

2

We faced similar issues when we moved to a monorepo structure last year. The solution that worked for us was implementing path-based triggers in our CI/CD pipeline combined with a proper tagging strategy. For selective deployments, we configured our build system to analyze git diffs and only trigger builds for services with actual changes. Most CI platforms support this through path filters or custom scripts that check modified files against service directories. Regarding stage promotion, we switched from using commit-based tags to environment-specific branches. Each service maintains release branches that get promoted through environments, making it much clearer what version is deployed where. For the approval process, we implemented branch protection rules that require pull requests even for release branch updates. This forces code review before any production deployment can happen. The key insight we learned is that monorepos require different deployment thinking than multi-repo setups. You need tooling that understands the repository structure rather than treating it as one giant application.