rolling out to production

[thelostone-mc]

Current Setup

Anytime you work on a feature :

1. a PR is raised against master branch
2. A test environment is deployed on fleek for testing that PR
3. Once the PR is merged in -> the latest code gets deployed to staging at https://rmgitcoin.on.fleek.co/
4. When we are ready to move to production -> a PR is raised from master to stable
5. One the PR is merged in -> the latest code gets deployed to production at https://round-manager.gitcoin.co/

Given this flow, there are 2 ways we can go about on How to get feature to production

Option 1

We remove the need for a master branch.
Once a PR is up, it's upto the team to test + give feedback in the PR and once merged -> it auto rolls into production

Benefits:

• Rolling Deploy
• No wait time from merge to deploy

Hardships:

• No safety net of master branch
• Product + Design would have to be involved in the PR review process

Option 2

Same as the current process but the only difference is, that it will up to the product to decide when features get merged from master to release. Engineering would help in automating creating tags / setting up changelog but product would hit the merge button and roll things to production

Option 3

Same as option 2 but the engineering team continues to have ownership with support from product on when and what to release to live

[shavinac]

On a previous team, we had "deploy days" (every Tuesday and Thursday), and if there were accepted features that were not in production yet, we would do a release on those days.
The dev who pushed the most recent commit to main branch was responsible for asking "do we have anything to deploy today" during standup on those days, doing the deploy to prod, and making sure it was successful.

Having specific days was helpful since it gave our PM a "deadline" for story acceptance, and stories were still deployed pretty frequently

[thelostone-mc]

On a previous team, we had "deploy days" (every Tuesday and Thursday), and if there were accepted features that were not in production yet, we would do a release on those days.

This would be going down Option 3 which I'm good with but it takes us away from a rolling deploy and the product has to be alright with releasing on those days and product + design would have to be due diligent to review everything merged before Tue / Thu

[nfrgosselin]

@thelostone-mc / @shavinac have we aligned on this as our rollout process? Could we document it permanently somewhere? I'd love to start crystallizing this flow

[thelostone-mc]

The process is documented as follows:

• PR will be raised against main and everyone will review them (including product + design)
• Every PR has to be rebased before being merged and testing

This is a rolling deploy

What is pending is for a way to auto-merge main -> release
We will experiment with this once the everyone is back and take a decision if this works/ if we need to change

[shavinac]

we could try using something like this https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#running-a-workflow-based-on-the-conclusion-of-another-workflow to trigger a "merge main -> release" workflow if the "build -> test" workflows on push:main were successful

[thelostone-mc]

I like that

[shavinac]

on passport, we had a workflow (file) set up to push main -> production branch with a manual button click (workflow_dispatch event), but we should be able to adapt it to run automatically for us after the build -> test workflow completes successfully