At my company (MousePaw Media), I've inadvertently served as the "devops" guy forever, and I've started anticipating many of these issues not far down the road. Thus, we are rolling out the following structure in 2018:
First, all programming department employees will have to pass our company's Repository Master training at some point. (I am currently writing this training material). Starting next summer, incoming interns will be required to pass Repository Master training as part of the internship program.
This training ensures employees understand the entire pipeline: the VCS (Git), static analysis (linters), dynamic analysis (memory checkers), build tools (CMake, Makefiles), code review, and the CI (Jenkins, Harbormaster).
While I'm creating the material to be primarily informative about our own pipeline, I'm also trying to ensure their understanding is solid enough to port to other companies and projects.
Second, we will have a formal Repository Master role. It is voluntary, and every developer is qualified to act in it, but only one or two are given the "power" at any one time. This is because acting Repository Masters have the ability to manage and bypass any part of the pipeline: they can fix problems, kick emergency bugfixes right into prod, tweak settings, configure repositories, etc. This is only to ensure the pipeline isn't damaged by 'too many cooks in the kitchen.'
Ultimately, the only privileges reserved for the Repository Masters are:
Bypassing the code review system (direct push to master and stable). Otherwise, any staff can land code that was reviewed and approved by any other staff.
Editing the repository's administrative settings.
Modifying the automatic CI build pipeline and triggers. (Any staff can create manual CI builds.)
Administrative control over the CI.
SSH into the build box.
However, because all the programmers have the training to act as Repository Masters, they are not dependent on anyone else to diagnose or fix most problems. They can untangle the VCS, use all the tools at their disposal, and diagnose when something breaks.
A couple of things you might want to think about though; if it's necessary to be able to "kick emergency bugfixes right into prod", this is telling you something about the rest of the pipeline, viz. that it isn't fast enough!
As for "direct push to master", yes it is switched on for me, but I'd like to get to a place where I could turn it off, even for me!
1) Our deployment speed is limited by the fact most of our team works only a few hours a week (side effect of being a work-for-shares startup). The pipeline is actually really fast given a full-time team, but we don't have that yet. Someday!
2) There are exceptions. "Oh crap, there's a broken link in the README" could go through code review, but you're wasting everyone's time at that point. Ergo, git push origin master.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice summary of the issue!
At my company (MousePaw Media), I've inadvertently served as the "devops" guy forever, and I've started anticipating many of these issues not far down the road. Thus, we are rolling out the following structure in 2018:
First, all programming department employees will have to pass our company's Repository Master training at some point. (I am currently writing this training material). Starting next summer, incoming interns will be required to pass Repository Master training as part of the internship program.
This training ensures employees understand the entire pipeline: the VCS (Git), static analysis (linters), dynamic analysis (memory checkers), build tools (CMake, Makefiles), code review, and the CI (Jenkins, Harbormaster).
While I'm creating the material to be primarily informative about our own pipeline, I'm also trying to ensure their understanding is solid enough to port to other companies and projects.
Second, we will have a formal Repository Master role. It is voluntary, and every developer is qualified to act in it, but only one or two are given the "power" at any one time. This is because acting Repository Masters have the ability to manage and bypass any part of the pipeline: they can fix problems, kick emergency bugfixes right into prod, tweak settings, configure repositories, etc. This is only to ensure the pipeline isn't damaged by 'too many cooks in the kitchen.'
Ultimately, the only privileges reserved for the Repository Masters are:
Bypassing the code review system (direct push to
masterandstable). Otherwise, any staff can land code that was reviewed and approved by any other staff.Editing the repository's administrative settings.
Modifying the automatic CI build pipeline and triggers. (Any staff can create manual CI builds.)
Administrative control over the CI.
SSH into the build box.
However, because all the programmers have the training to act as Repository Masters, they are not dependent on anyone else to diagnose or fix most problems. They can untangle the VCS, use all the tools at their disposal, and diagnose when something breaks.
Right, so basically you are me!
A couple of things you might want to think about though; if it's necessary to be able to "kick emergency bugfixes right into prod", this is telling you something about the rest of the pipeline, viz. that it isn't fast enough!
As for "direct push to master", yes it is switched on for me, but I'd like to get to a place where I could turn it off, even for me!
Regarding pushing bugfixes to prod, two things:
1) Our deployment speed is limited by the fact most of our team works only a few hours a week (side effect of being a work-for-shares startup). The pipeline is actually really fast given a full-time team, but we don't have that yet. Someday!
2) There are exceptions. "Oh crap, there's a broken link in the README" could go through code review, but you're wasting everyone's time at that point. Ergo,
git push origin master.