Improving R-Instat's delivery pipeline

[lloyddewit]

This discussion is about how we can improve our R-Instat delivery mechanism. By ‘delivery mechanism’ I mean the methods and processes we use to change, build, test and release R-Instat. This is sometimes referred to as ‘DevOps’.

This is a large subject.

On 15/06/21, @volloholic , @dannyparsons , @ChrisMarsh82 and @lloyddewit discussed appropriate GitHub branching models. I’ll start this discussion with some brief notes on this meeting. Meeting invitation:

In R-Instat, most of the features that we add are small enough to be implemented over a few days/weeks and be implemented in a single PR. Occasionally, we may wish to implement larger capabilities, spread over multiple PRs. We currently have a general principle that, when we merge a PR, the resulting updated R-Instat master branch should still be suitable for release. However, if we are implementing a larger capability in phases, then it may be difficult to adhere to this principle. Some software organizations manage this by promoting software through layers (e.g. development, test and production). The purpose of this meeting is to discuss whether we should take a similar (or alternative) approach for R-Instat. David asked me to arrange this meeting. It was triggered by the 'populate dialogs from script' capability. Ivan is currently implementing this. He needs to regularly merge his work to prevent conflicts.

We currently typically make a new release when we have an event that requires new features or bug fixes. The release typically includes everything that's on the current main branch. David would like to move to a model where we release a major version (e.g. 1.0, 2.0 etc) for example once per year; plus testing/beta releases for example every 3 months.

We discussed variations on typical GitHub branching models, as shown below.

We concluded that for the next release we would try and use an approach similar to the Cactus model. We would make a release branch and potentialy use this branch for a longer release testing phase. We would try and move towards the 'successful' model in time for the first major release (1.0).

Please feel free to add to the discussion! Thanks

Standard GitHub flow:

The 'successful' Git branching model:

Cactus model:

[lloyddewit]

On 29/07/21, Ian Stride mailed some comments and links:

When it comes to branching models, the simpler the better, in my experience. I think it would be useful to have a range of options from simple to complex, with projects always tending towards the simplest model and only progressing to more sophisticated models when there is a clear need. The projects I have worked on in the past have used git-flow, github-flow and trunk-based development (TBD).

I would expect that github-flow or TBD would be sufficient for IoGT, as it is a web app and would benefit greatly from Continuous Integration and Continuous Deployment, and I think a model that includes release branches may hamper that. I don't know enough about the other projects to confidently make a recommendation, but I would not be surprised if they would benefit from a more complicated branching model like git-flow, if they have longer release cycles and a requirement to support previous releases.

Much like with naming conventions, I think each project has to decide what is best depending on its particular circumstances, but providing guidance on the available options is very important.

On 13/08/21, @ChrisMarsh82 created a Wiki page on this subject:
https://github.com/africanmathsinitiative/R-Instat/wiki/Branches-and-Releases