Release guide

Developer-oriented guide to named release branching process.

This concerns how delivery teams interact with the release process via a branching strategy rather than the wider release process.

Steps

Release candidate branches may be merged into master once the previous named release completes E2E testing.
- Mark to own updates on completion of E2E testing.
- Developers to own:
  - Review and merge of release candidate branch into master. Features should be already reviewed, so this involves sanity checking, in particular merge conflicts in the changelog.
  - Monitoring of Integration tests in latest after merge to master.
Once a release candidate branch is merged into master and is passing integration tests, it may then be released when requested by GEL.
- GEL to request releases, via Mark.
- Mark to open ticket against Dave.
- Dave to follow full release process from there to deploy to E2E.
E2E testing of this release candidate begins. If any defects are raised:
- Developers to perform initial triage and attach any extra info to the defect.
- Tom to decide whether fix is made to the named release under test (HEAD of master) or to a later named release (still in candidate branch).
- Developers to apply fix to specified version, and propagate this back out to later release candidate branches.

Example flow

Labelling of commits in the git tree diagrams below is as follows

* <hash> <branch head>? (release candidate branch) [<environment(s)>]

Initial state

Edouard has already been released. Development of Fay is complete in the rc/fay branch.

* 2f9768a6 master (rc/edouard) [latest, E2E]
  \
    \
      * rc/fay

Testers inform Mark that Edouard has passed E2E testing. Developers then perform final review of rc/fay and merge it in. Integration Tests against latest are then monitored by developers, and any failures triaged and resolved as top priority.

After merge

Fay has been merged and is passing Integration tests in latest. Subsequent work for Gonzalo is performed on new release candidate branch.

* 2f9768a6 (rc/edouard) [E2E]
|
|
* fb98d245 master (rc/fay) [latest]
  \
    \
      * c69e7520 rc/gonzalo

Release to E2E

GEL requests release of Fay to E2E testing. Mark raises release ticket and assigns to Dave who triggers release from HEAD of master.

* 2f9768a6 (rc/edouard)
|
|
* fb98d245 master (rc/fay) [latest, E2E]
  \
    \
      * c69e7520 rc/gonzalo

(Optional) Defect raised in E2E

A defect is raised in E2E. Developers perform triage and the PO prioritises and asks for a fix against Fay. Developers apply the fix against master, and ensure this is applied to rc/gonzalo. Below this is shown as a rebase for simplicity, but may be achieved via merging or cherry-picking.

* 2f9768a6 (rc/edouard)
|
|
* fb98d245 [E2E]
|
|
* 40d5ba5c master (rc/fay) [latest]
  \
    \
      * c69e7520 rc/gonzalo

Mark opens a ticket to release a hotifx version of Fay containing the fix.

* 2f9768a6 (rc/edouard)
|
|
* fb98d245
|
|
* 40d5ba5c master (rc/fay) [latest, E2E]
  \
    \
      * c69e7520 rc/gonzalo

jacksmith15/developer-release-guide.md