Merge Requests and Pipelines

Merge Requests and Pipelines¶

Contents¶

Submit a merge request and monitor its pipeline
- Create a merge request
- Troubleshoot a pipeline failure
- Get your MR reviewed
- Merge and deploy your MR
- If an MR is reverted
Package versioning
- Major Features
  - Examples of Major Features
- Minor Feature
  - Examples of Minor Features

Submit a Merge Request and monitor its pipeline¶

Note: For submitting MRs to amu_webapi, you need to deploy your MetalFly API cluster to each region ONCE, otherwise MR will fail with deploy:Core:dev [region] error. See the Troubleshooting Guide for more details.

If your MetalFly API cluster is already deployed, you do not need to deploy it again.

Create a Merge Request¶

Clone your repository.

git clone git@ssh.gitlab.aws.dev:amazonmusic/musicfirefly/amu_webapi.git

Make your changes in a new git branch:
```
git checkout -b my-feature-branch main
```
Note: We do not want to track origin/main because we don’t want to accidentally push an unapproved change to main
Evaluate your changes for compliance with the Development Guide.
- Please include any appropriate test cases. Integration tests are required and are conducted automatically.
Create your commits and MR using Commitizen:
```
git cz
```
Commitizen applies the prefix that will determine how the version number is incremented. If not correctly incremented, the pipeline will break, or the changes won’t deployed. The main prefixes are: fix:, feat: or breaking:.
- If you do not have Commitizen installed, return to the Developer Onboarding guide.
Push your commit(s) to your own feature branch
```
git push -u origin my-feature-branch
```
You can push changes to your feature branch during your development cycle, as all commits on the branch will all be included in your Merge Request.

Warning: do not push changes to Main
Issue a Merge Request from your branch once its ready for review.
- If you navigate to amu_webapi, it should show a button to create an MR automatically.
Check your MR’s pipeline status on the Pipelines tab.
- Each MR has its own pipeline that builds your changes, runs tests and checks for approvals.
- Make sure your pipeline passes all integration tests before contacting reviewers.

Troubleshoot a pipeline failure¶

If you see a failure, before contacting Devex API team, try rebasing from main so your code changes are up to day. .
See the FireFly team’s forum on Sage to search for help, ask questions, and make suggestions for FireFly documentation.
Check #music-firefly-interest on Slack to see if there’s an ongoing related issue.

Get your MR reviewed¶

The final stage of the pipeline is approved. This job will leave a comment on your MR listing two developers from the Devex API team who are assigned as reviewers.
Please message them individually over Slack to let then know you are waiting for their review.
The FireFly team has an SLA of 2 days, therefore we should get back to you within that time period for each round of feedback.
- You may be asked to make changes and await approval again.

Merging and deploying your MR¶

The merge-train label is added to an MR in Gitlab when all tests are complete and it has met approval requirements, indicating it will be automatically picked up by the merge schedule.

The FireFly team has automated the MR merging pipeline to run every 10 minutes, 24/7.
We have also automated the production deployment pipeline to run from Monday to Friday at 9 AM. In other words, any change merged on a given day should be merged at 9 AM the following work day.

If your merge request is reverted¶

The FireFly team may need to revert your change in the event of a Sev-2, a broken pipeline, or another emergency in order to get production back to a previously working state.

In this case, we may ask you to re-submit your merge request if we cannot directly commit and merge the change again as-is. A new MR is typically required when there are merge conflicts after rebasing your change.

Package Versioning¶

Major Features¶

Major Features can be classified as any modification to the Grapqhl Schema a client will be interfacing with. This information includes Queries, FieldResolvers, Mutations, and Subscriptions.

When a Major Feature is submitted, this will be subject to additional scrutiny compared to a Minor Feature due to modifying a contract between a Client and the Service.

It is required to follow the Development Guide to reduce back and forth, and it is suggested that Office Hours are scheduled ahead of review to help with any data modeling and use-cases.

Note: FieldResolvers are treated on a case-by-case basis. FieldResolvers that append a single property that aligns with existing schema’s will be treated as a Minor Feature (ie: TotalCount to a Connection, type information on an Image).

Examples of Major Features¶

New Entity Introduced to the Model

@ObjectType
Foo {}

New Query/Mutation Introduced to the Schema

@Query
Foo ({})

@Mutation
DoFoo ({})

Field Resolver that extend a new Entity

@ObjectType
Bar {}

@FieldResolver
Foo(): Promise<Bar> {...}

Minor Features¶

Minor Features can be classified as modifications to the stack that do not modify the interface and are less than 100 Lines of Code.

Examples of Minor Features¶

Modifications to Transformers
Modifications to a Dao that does not require modifying an integration test
Adding a FieldResolver that returns an existing Entity Type or Primitive

Firefly