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>.
- Once your feature is complete, push your feature branch to git and create a merge request in GitLab.
- Use the following release type terms within the title of your GitLab merge requests. For example, "Company - Service name - Alpha 1".
- Feedback or defects will be communicated as GitLab issues.
- Once the branch has been accepted we'll merge your submission into the DEV branch.
- 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.
- Approval to proceed to UAT can be documented using GitLab comments on the merge request.
- 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
- {steps to enable these changes}
- {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
- Roll out the code changes
- Enable the FooBar module drush en foobar
- Add the API key in the admin page /admin/foobar