Hi, Curious ... has anyone here successfully dropped github branch protection enforcement in favour of something else (eg. rulesets or similar) to unlock velocity and remove friction in your CICD without introducing too much auditor (SOC2) headaches/overhead/admin to factor in? If so, would you be open to sharing some thought topics for me to consider, before I head down this path soon, please? 🙏 Looking for some inspiration & lessons learnt if possible, please.
This post is now synced! Check it out here:
Has Anyone Successfully Replaced GitHub Branch Protection to Improve CICD Without SOC2 Issues?
⤵️ Any future comments will be automatically posted to the thread
How does branch protection seem to get in your way?
ATM, it seems to be a friction point from my EM's. Hence why we're looking to make it more effective to our needs.
Thanks Eric - yes, that's the middle ground we're considering ATM if I can't find a different way enforce the review validation step. thanks
Yeah, we just do main and production branches as protected. Any feature branches are unprotected. This allows developers to code anything they want push as much as they want and only when they make their MR into the "staging" branch is the protection needed so they don't do git push origin main --force and wipe out everything.
This is an excellent process https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
Hi, follow up on this, Ensure branch protection rules are enforced for administrators (GitHub), I created a Bypass list for Admins and Mgmt.. so this test fails, what would the correct way to get this fixed? I'd like to have at least for the core mgmt and me (CTO) to be able to bypass these restrictions
Markus S., out of curiosity, why even risk pushing directly to a branch? What in the SDLC process do you find limits you? I'm happy to help you if you'd like
Patrick L. thanks for the reply.. Well, I think this comes from a place where the core team can quickly react and push to master in (hypothetical) high stress situations.. more like a safety net.. then again, you can always deploy a branch with an emergency fix.
yes. Mostly as a break glass option, but restricted to a few that can make that call. ie. Leadership & on-call folks. Most as an emergency option. Not to be used as the daily driver.
Yes, added just 3 people (including me), but the automated test still is failing in Vanta. That's too bad
For that specific need, in $prev we ended up using github rulesets to handle the logic, and then when Vanta flagged failure, we dismissed the action with an exclusion comment, which I had approved. not a clean way to handle it, but it was ok for us at the time. NOTE: AFAIR, Vanta does not yet fully support github rulesets logic , which is actually a stronger & more granular control than branch protection. Would love to see Vanta supporting rulesets better. 🙏
Markus S. So for us that would be a hotfix branch so from main git checkout -b hotfix/production-issue-abc then you can run your CI/CD process to validate and push it on merge into main
