Hey folks! I'm currently diving into DevOps and have been working on configuring our CI/CD workflow at my job. Since we're using internal servers and the company prefers not to invest in cloud solutions, I've been exploring free and open-source options as I learn.
Right now, I've set up a basic infrastructure as code with bash scripts to manage our self-hosted runners from GitHub. I also have a Docker registry for our various repository images and workflows established within each project.
Here's how the workflow operates: when someone opens a pull request (PR), a Docker build is triggered, and that image gets sent to the registry. However, the issue arises when multiple PRs come from the same base branch—if PR A is merged, it deploys that build, and if PR B is merged later, it only deploys the changes from PR B, leaving out what was in PR A. For both PRs' changes to appear in a deployment, I would have to create a new PR C after merging the others.
I've been trying to follow the principle of "Build once, deploy everywhere," but I'm starting to think about the idea of "Build on Merge." Isn't that a contradiction to the first principle? Can anyone share their workflow strategies or tips for managing this better?
1 Answer
It seems there’s a misunderstanding of the "Build once" concept. Whenever a PR merges, build the new main branch as a whole and deploy that single build through all environments. The idea behind this is that you'd only make a final production-ready image once the main branch changes.
Exactly! With trunk-based development, just think about building whenever there’s a change in the main branch. That way, both PR A and PR B will be incorporated into a single deployable build.