I manage about 15 microservice repositories and want them all to run similar pull-request and main-branch workflows. With shared workflows, each repository still needs to reference the workflow and provide its inputs. If I add a new input or change a feature, I have to update and merge changes across many repositories. Since workflows are evaluated from each repository's branch, workflow changes can also become tied to release branches and pull requests, which is inconvenient and can cause problems when a workflow variable is wrong in a release branch.
I'm looking for a CI/CD platform or setup where automation rules and shared workflow code live in a separate repository from the product code. Ideally, one central repository could define triggers such as pull requests and main-branch builds for all 15 services, while still allowing service-specific configuration and controlled versioning. What tools or architectures handle this well?
4 Answers
You may want a pipeline system that treats pipeline definitions as centralized configuration rather than files shipped with every application. Azure DevOps YAML pipelines and Argo Workflows are examples worth evaluating. They can separate orchestration from service repositories, though the exact setup depends on whether you need hosted CI, Kubernetes-native workflows, or both.
Another option is to package the behavior as a versioned action or automation component in its own repository. Services consume a released version, and a dependency update tool can automatically open update changes whenever a new version is published. The update is then tested in each service before being merged, which gives you controlled rollouts and a clear way to handle breaking changes.
If the main issue is that workflow changes are stuck behind every open pull request, automatic rebasing or merge trains can reduce the friction. That won’t fully centralize the configuration, but it can make changes to shared workflow references roll out more smoothly across active branches.
A common approach is to keep reusable workflows in a dedicated, centrally managed repository. Each service repository calls the appropriate workflow, and access to the workflow repository can be limited to the infrastructure or platform team. This keeps the automation implementation separate from application code, although each service still needs a small reference to the shared workflow.
That works for standardizing the implementation, but it doesn’t completely remove the rollout problem. If repositories pin a commit or version, changing inputs still requires updates in the callers, and different services may need different parameters.