I'm setting up a CI/CD pipeline where I want to build an artifact only once and then promote that same artifact through DEV, UAT, and PROD without having to rebuild it for each environment. Right now, I'm trying to nail down the best source code management strategy.
In Bitbucket, I've seen teams either use multiple branches like dev, uat, and prod or take a trunk-based development approach with just a single main or master branch. I'm leaning towards trunk-based development since it keeps things simple with a flow where:
- Development happens solely on the main branch.
- Any push to main triggers the pipeline.
- It builds an image tagged with the git SHA, pushes it to the registry, and deploys to DEV.
- For UAT, I can tag the commit from DEV, fetch its SHA, check if the image exists, and deploy the same image to UAT.
- The same goes for PROD.
This flow seems tidy and supports true "build once, deploy everywhere." However, when teams are using multiple branches, how can they realistically achieve artifact reuse without rebuilding code? Should we standardize on a single main branch and promote using tags or approvals? I'm open to any alternatives that allow for a "build once and reuse the same image" approach!
5 Answers
Most teams find that using trunk-based development with GitFlow works well. We deploy our releases from the dev branch to development environments, then merge to master for UAT and PROD. This way, you ensure consistency and can easily track versions.
Have you considered using ArgoCD with Kargo? It's super effective for managing your deployments and can help with the artifact promotion across environments without extra hassle.
I'm all for binary promotion over source promotion! Sure, people love their branches, but it can create issues with hot fixes for production. Anyone dealt with this before?
I've faced those challenges. Make sure your artifact is immutable—that makes things so much simpler.
Your approach is on point! Rebuilding for each environment is a hassle. Having everything on the main branch keeps it cleaner—rebasing and fast-forwarding will make your life easier. Trust me on this!
Trunk-based development with a release branching strategy is definitely the way to go! This allows you to cherry-pick commits when necessary, making it easy to roll things out to production quickly if needed.
You don't actually need a release branch for hot fixes in trunk-based development. It can just slow things down without providing significant benefits.
We do the same! It helps track which images are in each environment, and you can always tag them for reference later.