A separate post to give an idea of my frames of reference. At $day_job, my role is now architecture and integration to support SysAdmins (which I used to be). To do that, and to support a varied environment consisting of many flavours of Unix, Linux, Hypervisors and hardware architectures, we implemented a configuration and compliance management tool known as Puppet. Puppet uses it's own structured language to describe system end-states, and maintain them as a configuration and compliance engine. So, basically, you have infrastructure as code.
So, when you have code, and a need to maintain transparency and sustainable, reproducible infrastructure, you need a version control system. Originally, that was Git and Trac for us, and we made the switch to GitLab a few months ago for better productivity and for integration into other tools like Jenkins. Because, when you deal with almost every form of *nix out there, keeping your infrastructure tooling consistent across all platforms is challenging. You can't always ensure that the vendors will be shipping exactly what you need, and so you can be dealing with even more variety in your tooling as well as the stuff your're trying to maintain! It's enough to make you want to smash something! So, sometimes you need to roll it yourself in order to ensure you have what you need, just the way you need it, when you need it. So, we use Jenkins for building packages to ensure our infrastructure tooling is in lockstep across all platforms.
So, basically I'm a SysAdmin using GitLab to maintain the tools my team needs to manage hundreds of systems. Our Git workflow represents a fairly linear model as a result. We're just always making releases to increase capabilities or service catalog products, or just to deal with the fact that things change (like System V init to systemd). As such, we maintain a fairly simple workflow.
Master is always production-ready. Features get developed in their own branches. The develop brand is where integration happens, and dedicated "life-cycle systems management" instances are subscribed to that branch for dev/test and regression testing. Releases are tagged, and pulled into master. Master gets pulled into the systems management tool, and applied to client test/dev systems. Upon acceptance from them, they get applied to validation systems. If those are good, it gets air-gapped across to client staging/pre-prod instances and tested against a back-flush of prod. Assuming no regressions, it gets promoted to Production systems. Rinse, repeat for next cycle.
So, in a lot of ways, workflow gets determined by how much risk someone is willing to accept. In a high availability environment, very little risk is accepted; hence a rigorous process with many gates and go/no-go decision points. Tooling always has to support the process. More risk tolerance lends itself to more of a continuous-integration type workflow, where small changes are integrated often and distributed widely, and the tooling usually supports a quick reversion capability if things go badly.
Most of the opensource projects that get used in the enterprise space operate on a two-pronged approach. Nightly builds for those who develop or who like living on the edge. Stable releases are for those who have to depend on it.
So, do we want to model or mimic workflows of similar projects (some of whom are on GitHub)? The fork, branch, pull-request model does work well for most of those projects. We just need to consider the other tooling (like the builders) and the overall release process for getting it out into the wild. However, LinuxMCE has challenges that something like OpenHab or AgoControl won't have. LMCE's "auto-magic" functionality requires deep hooks into operating system components, and those are OS version specific. So our processes and workflows may need to consider and allow for supporting an 'n', 'n+1', and 'n-1' release strategy. Branching may or may not reflect that strategy, depending on how other processes and tooling handle it.
We have community contributors, and there's also Dianemo/CHT. Do we treat them any different from the community? GitLab allows for personal workspaces and team workspaces... GitLab also allows for branches to be "protected", limiting those who can commit to it. This is a good idea for production branches.
More food for thought. Opportunities to cast aside legacy, and the cost is to consider all the options, and possibly blaze a new trail.
/Mike
