this post was submitted on 21 Jul 2023
170 points (94.3% liked)
Programmer Humor
32479 readers
239 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Yes, but Gitlab doesn't allow for easy access rules.
Basically, OPS wants full control of the repo, since they are the ones being blamed if something goes wrong. There's no way to enforce, that only a certain set of users can make changes to a branch - all such restrictions can be circumvented rather easily. So the solution is a shadow copy of the repo that only gets updated on release and Argo only deploys a specific tag (i.e. release).
We're not talking about just some enterprise microservice, but stuff in the public administration/government sphere. The tradeoffs are a bit different there.
I didn't know that GitLab doesn't allow that! We use BitBucket and there it's extremely easy to put branch restrictions so that only certain Usergroups are allowed to merge into the release-branches
Bitbucket also doesn't enforce these rules properly. You can simply change the rules, merge, then change back.
The only way around that is to restrict every developer account into oblivion and only have an ops guy as repo admin, but I think most ops teams have better things to do.
Why should a developer be a Repo admin? Thats DevOps territory
That very much depends on your workflow and team setup. Repo admin for me means "can alter who and how branches can be merged". That's usually a job for lead devs.
Aah, DevOps as a separate role... Now that's a dream I can get behind...