|
|
|
Follow the steps below when submitting a Merge Request (MR) for all development updates to production websites:
|
|
|
|
Drupal developers must follow the steps below when submitting a Merge Request (MR) for all development updates to production websites.
|
|
|
|
|
|
|
|
**Developer steps:**
|
|
|
|
|
|
|
|
1. Commit code updates from local dev environment feature branch to Gitlab. This will trigger a Gitlab CI/CD pipeline to build your feature branch site with new updates in our non-prod environment for MR review.
|
|
|
|
2. Inside Gitlab, click on the link provided at the top of the Gitlab UI to setup your MR.
|
|
|
|
3. Provide the following items on your MR (as part of `Standard` MR template):
|
|
|
|
2. On Gitlab account, click on the link provided at the top of the Gitlab UI to setup your MR.
|
|
|
|
3. Select the `Standard` MR template for routine updates and fill out the following items:
|
|
|
|
1. `Summary` - description of your update with ES story number. (e.g. STRY1234567 - update to x so that y)
|
|
|
|
2. `Steps to Test` - list of steps to test your update in your feature branch build.
|
|
|
|
4. Set `Assignees` to developer who will review/test MR.
|
|
|
|
4. Update `Assignees` (upper right corner) to the developer who will review/test MR.
|
|
|
|
5. Save `MR` and ping developer in MR `Comments` to start reviewing.
|
|
|
|
6. Update development story in ES portal to change state from `Work in Progress` to `Developer Peer Review` and update `Assignee` field to developer who will review MR.
|
|
|
|
7. Upon completion of MR review, developer should ping BA for final testing in MR `Comments`.
|
|
|
|
8. Developer should then update story in ES portal to change state from `Developer Peer Review` to `Testing` and update `Assignee` field to BA who will complete final review of MR.
|
|
|
|
9. |
|
|
\ No newline at end of file |
|
|
|
6. **IMPORTANT** - Update your development story in ES portal to change state from `Work in Progress` to `Developer Peer Review` and update `Assignee` field to developer who will review MR.
|
|
|
|
|
|
|
|
**Developer Peer Review steps:**
|
|
|
|
|
|
|
|
1. Upon completion of MR review `Steps to Test`, developer should ping BA for final testing in MR `Comments`.
|
|
|
|
2. **IMPORTANT** - Developer should then update the story in ES portal to change state from `Developer Peer Review` to `Testing` and update `Assignee` field to BA who will complete final review of MR.
|
|
|
|
|
|
|
|
**BA Testing steps:**
|
|
|
|
|
|
|
|
1. BA should confirm a Standard or Normal Change Request (CR) has been added for the development work as needed. If no CR, BA should create one based on Acceptance Criteria and Technical Approach info on story in ES portal.
|
|
|
|
2. Upon completion of MR review `Steps to Test`, BA should ping main developer to indicate testing is complete in MR `Comments`.
|
|
|
|
2. **IMPORTANT** - BA should then update the story in ES portal to change state from `Testing` to `Product Owner Review` and update `Assignee` field to product owner (e.g. Dennis or Bill) who will complete final review and mark story as complete.
|
|
|
|
|
|
|
|
**Merging Updates:**
|
|
|
|
|
|
|
|
1. **MOST IMPORTANT** - developer who completed peer review of MR should only merge the updates when they have confirmed a CR has been added for the update and approved (or scheduled).
|
|
|
|
2. Once approved CR has been confirmed, use `Merge` option on MR to merge changes to upstream master branch of project. |
|
|
\ No newline at end of file |
