How to make a merge request

Date adopted: 
August 28, 2020
Last update: 
August 28, 2020

We have merge requests to:

  • communicate between parties;
  • verify work;
  • support our change management process;
  • create accountability and traceability;
  • provide history;
  • document work; and
  • improve deployment repeatability.

The government uses the GitLab merge request feature to request code changes. Merge requests are called "pull requests" for all non-GitLab Git users, like GitHub.

Pull from the dev branch of the git repository and create your own branch to develop your feature/site. We do not allow direct "push" access. We recommend the following naming convention your branch: <vendor-name>/<description-of-work>.

  1. Once your feature is complete, push your feature branch to git and create a merge request in GitLab.
  2. Use the following release type terms within the title of your GitLab merge requests. For example, "Company - Service name - Alpha 1".
  3. Feedback or defects will be communicated as GitLab issues.
  4. Once the branch has been accepted we'll merge your submission into the DEV branch.
  5. Once a "release candidate" is deployed to DEV branch, eServices will need approval from the project team to proceed to deploy any work to UAT.
  6. Approval to proceed to UAT can be documented using GitLab comments on the merge request.
  7. Once features/site has been approved in UAT by eServices, those commits containing the relevant features can be pulled into production.

Merge request template

Title

The merge request title should be in the format: {Company name} - {project} - {release}

Examples of titles:

  • CompanyA - Open data CSV harvest - alpha 2
  • CompanyB - HSS - RC 2
  • CompanyC - ENV Permit hunt authorization - RC 3

Target

Nearly always the dev branch.

Description

This work includes

  • {feature 1}
  • {feature 2}
  • {...}

{feature 1 title}

{Feature 1 writeup}

{feature 2 title}

{Feature 2 writeup}

{...}

Known issues

{List of outstanding items, incomplete aspects or other pitfalls}.

Notes

{Pertinent details about this work}

Deployment instructions

  1. {steps to enable these changes}
  2. {preferably using command line}

{simple instructions to verify that deployment worked}

Sample

Title: Devers - Pinball - RC1

This work includes

  • Foos page
  • Dinglehoper reduction

Foos page

This release includes a new module, FooBar, which collects all the Foos on a single page. This is done using the Foo services, which requires an API key. {...}

Dinglehoper reduction

By varying the fizzlebender, the site now uses substantially fewer dinglehopers. This applies to all page except /user which is totally infested.

The new Foobar should be visible at /all/you/foos.

Known issues

This release include only a partial implementation of the fizbat system.

Notes

After discussing with the client, we agree to limit the number of Foos displayed to factors of 42. This was done to please the pixies. If it needs to be changed, check the constant name FOOS_PER_PAGE near line 934.

Deployment instructions

  1. Roll out the code changes
  2. Enable the FooBar module drush en foobar
  3. Add the API key in the admin page /admin/foobar