Workflows
Wiki ▸ Workflow
We (tend to) use a Feature Branch Workflow: it is simple and it is working in real life.
For more complicated productions, release-like, we could adopt GitFlow (see also "A successfull Git brancing model"... or Intro to GitHub Flow and this blog)
We have one source repository:
-
aiu-portal: where we define the structure and content of the site. To do so we use the (Hugo) framework.
The repo typically has 3 branches:
-
master: this is the production branch and reflects what is being publicly visible on the web. -
<4-digit-year><2-digit-month>-release: the branch where we work on next release version of the portal. Opening a Pull Request on this branch triggers the creation of a preview by Netlify at something likehttps://deploy-preview-##--aiu-portal.netlify.app/where##is the number of the PR. -
<4-digit-year><2-digit-month>-release-fix<whatever>: a typically short-lived branch where we prepare a fix for production.
For experiments or studies of new features we can create other branches.
We have 3 types of routine activities:
- development of next portal release
- fix of currently published release
- publication of a (fix/update of a) release
Development happens in a branch named <4-digit-year><2-digit-month>-release, i.e. 201606-release,
and is performed by a team member playing the role of a Contributor.
Fixes or updates to currently published content are carried out by a team member playing the role
of a Maintainer in a branch (of latest master) conventionally named
<4-digit-year><2-digit-month>-release-fix<whatever>, i.e. 201606-release-fix-DO-IT.
The publication of (a fix of) a release is triggered by a team member playing the role of Integrator and performed automatically by Netlify web services.
The following diagram summarizes where and who does what:
The contributor workflow is the bit of work that happens when we prepare the next release of the website.
We work in a branch conventionally named <4-digit-year><2-digit-month>-release, i.e. 201606-release
for the June 2016 release.
This workflow is further elaborated in the Contributor Workflow page.
The maintainer workflow deals with the development of fixes or (somewhat urgent) updates between releases.
We work in a branch conventionally named <4-digit-year><2-digit-month>-release-fix<something>, i.e. 201605-release-fixME for an update of published May 2016 release (while we are developing the June release).
This workflow is further elaborated in the Maintainer Workflow page.
The integrator workflow is used to transfer (fixes/updates of) releases to the master
branch in order to officially terminate development or bug fixes.
We work in a branch as created in the maintainer or contributor workflow.
This workflow is further elaborated in the Integrator Workflow page.
The publisher workflow is used to publish (fixes/updates of) releases. This workflow is automated via the use of cloud services as provided by Netlify.
This workflow is further elaborated in the Publisher Workflow page and displayed in the diagram below:
