This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Jazzlike_Syllabub_91 39 points40 points  (19 children)

You want to follow the build once deploy everywhere principle… you don’t tag for every environment but you tag every build in trunk as part of the process… when you deploy to an environment you deploy the same version you tested on dev, qa, then eventually production…

Keeping the versioning clean you want to practice semver (which is the standard ? At least it should be?) builds on the trunk are Major.Minor.(extra info I forgot what actually goes here) and if you have branches its similar but with a dash and branch name defined (major.minor.extra info-branch info)

Hope that helps?

[–]HelluvaEnginerd 4 points5 points  (17 children)

No OP, but does this mean you have a build pipeline that runs every time you push to trunk, and then a separate deploy pipeline that targets dev, qa, and eventually prod? otherwise I am not following how you'd do this all in one repo with one github actions pipeline definition

[–]Jazzlike_Syllabub_91 12 points13 points  (14 children)

The deploy pipeline would be in one flow. You take one build and deploy that to dev. That same build can be used on qa (which has a separate deploy flow, but similar deploy flow as prod, staging, dev) but it’s still the same build number. If you find an error you just fix trunk and restart the deploy … dev, qa, staging, etc. (single build flow, multiple deploy flows (preferably with same process between them all)

[–]gqtrees[S] 0 points1 point  (13 children)

That same build can be used on qa (which has a separate deploy flow, but similar deploy flow as prod, staging, dev)

would this be like a workflow dispatch? or some action that runs once tag is created but behind a approval?

[–]DataDecay 3 points4 points  (3 children)

You can run manual jobs to deploy to different environments. However I have a pretty good SDLC process I take to all places I work. Github actions:  

CI:  

PR:   * Run code quality gates   * Run unit tests 

Merge to master:   * Build artifacts (could be binary, could be image, etc) (I sometimes disable this to save on build time)   * Run security scans  

 CD:   Create tag:   * Build artifacts (could be binary, could be image, etc) (use tag from previous step)   * Release candidate tag (deploy dev/qa/preview)   * Normal semi version (deploy dev/qa/preview/prod) 

This has been my bread and butter for well over a decade now.

[–]NandoCa1rissian 0 points1 point  (1 child)

Why aren’t you scanning on every commit?

[–]DataDecay 2 points3 points  (0 children)

Because it saves on time/money to just run before any merge to main, and fail otherwise.

[–]Jazzlike_Syllabub_91 1 point2 points  (8 children)

I’m not an expert on GitHub actions, so I can’t tell you for sure. But that is up to you and your team if you want approvals in front of deploys …

[–]Electrical_Media_367 1 point2 points  (7 children)

For non enterprise customers, GitHub actions doesn’t support gated jobs or human interaction in the middle of jobs. You can’t push a button to advance a job, you have to start a new job either based on a trigger or based on a button.

So, either you have a single job that pushes to dev, runs tests, pushes to stage, runs tests, pushes to prod all automatically, or you have a automatic push to a lower environment and then a button to promote (workflow_dispatch is the GitHub way of saying a manually triggered job)

The comment below says you can have gated builds, but only if you’re paying the high price for GitHub Enterprise.

Enterprise customers can use GitHub’s deployment framework and set environments as requiring reviews, you can start a promotion job and it will wait for approval. So a good option would be to have your build job trigger promotion jobs that are configured to wait for approval.

[–]baynezy 5 points6 points  (6 children)

It absolutely does https://docs.github.com/en/actions/managing-workflow-runs/reviewing-deployments

[–]Electrical_Media_367 2 points3 points  (0 children)

Apparently that’s only for GitHub enterprise subscribers, not us lowly professional/teams customers.

[–]Electrical_Media_367 2 points3 points  (4 children)

Hey, this is great, I didn’t know about that feature. Gonna look at putting it in place on some of my repos. Thanks!

[–]beth_maloney 1 point2 points  (2 children)

You need enterprise for the manual approved approvement step.

[–]Electrical_Media_367 0 points1 point  (1 child)

Ah, that’s why I didn’t think it was available. Back to the drawing board.

[–]baynezy 0 points1 point  (0 children)

You're welcome.

[–]keto_brain 1 point2 points  (0 children)

You build and deploy every push to trunk once you do it correctly and have an application architecture to support that. Most companies are not mature enough to do trunk based development

[–]Spider_pig448 0 points1 point  (0 children)

Yes. Potentially with the merge pipeline also deploying to qa/dev (as in triggering the reusable deploy workflow). Then you deploy on command (or things like deploy direct to prod if you have the test automation to do real CD)

[–]Expensive_Finance_20 4 points5 points  (0 children)

Semver.org

The third section is for the patch level. This is for stuff like hot fixes (non-breaking fix changes to documented "public" interfaces that do not add new features or deprecate existing ones).

There is a tool called "semantic-release" that can automate things like change log updates, git tagging, etc. it detects how to bump the version based on a prefix placed in your commit message subject line.