I'm working on a comprehensive DevOps learning project using Azure Pipelines, Docker, ACR, Kubernetes, Helm, and Terraform, and I've run into a decision point about how to structure my repositories. I currently have a mono-repo that holds everything—app code, Terraform, Helm charts, and CI/CD pipelines. However, when I rebase my feature branches with the main branch, I end up pulling in commits related to infrastructure and pipeline definitions, which feels a bit messy and unprofessional. I'm wondering if I should move the CD pipeline and infrastructure code to a separate repo. But that raises the question: how can the CD pipeline know when there's an update to the app repo's develop branch? I've considered options like pipeline resources, webhooks, path/branch filters, and CODEOWNERS for protection, but I'm curious about what practices professionals use in production. Is it better to stick with a mono-repo and use careful filtering, or is having separate repos with automated triggers the way to go? How do experienced DevOps teams manage this separation while ensuring smooth automated workflows for app code changes and infrastructure deployments?
5 Answers
Has anyone tried a 'build once, deploy many' strategy? We’ve been moving the same artifacts from development straight to production, using build tags to track everything. I have to say it’s been a hassle at times. Just curious what other strategies folks might be using!
From my perspective using GitHub, we handle this with a focus on feature branches and a main branch. Once a PR is merged, we use a tool called Release Please to create a new release tag, like `mobile-v1.2.3`. Our GitHub Actions workflows trigger on these new releases. So, when infrastructure code changes, it creates a corresponding release that our workflows react to. This system allows for clear separation of concerns since the release and tagging strategy defines how we handle our changes across a monorepo setup.
While I'm still learning about Terraform and Helm charts, I can say that for our pipelines, we keep them as a wrapper function within a separate library repo. This way, changes to the library don’t impact the code repos directly since they only pull in the library at pipeline runtime. This might be an approach you can consider!
Here's how my team has structured things: we have separate repos for pipeline templates and Helm charts. Each application repo contains its Dockerfiles and pipelines. When a chart is built and uploaded, a separate repo is also updated with the version. This setup lets us release builds quickly and keeps things flexible with the platform team's changes.
It's really all about preference and execution these days. There's no one-size-fits-all approach, and different teams find success with varying methods.
Related Questions
How To Get Your Domain Unblocked From Facebook
How To Find A String In a Directory of Files Using Linux