How we work: Branching strategy

Development flow

1. Create a feature branch using main as the base branch

   1. git checkout -b fer/1234
   2. Our feature branch naming convention is an abbreviation of the author's name / the issue number. For example fer/1234

2. Deploy your changes to staging

   1. In your local environment, checkout the staging branch and pull the latest changes
      1. git checkout staging && git pull origin staging
   2. Squash and Merge your feature branch to the staging branch
      1. git merge fer/1234
   3. Push the changes directly to staging. No pull request is required.
      1. git push origin staging
   4. Deployment to the staging environment will be triggered automatically

3. Move the issue to the PO Acceptance column in the Kanban board (if the issue can be reviewed externally)

   1. Wait for external review
   2. If external review is APPROVED ✅
      1. Move to step 4
   3. If external review is NOT APPROVED ❌
      1. Go back to step 2 (Iterate your code until it is PO accepted)

4. Create a Pull Request

   1. git push origin fer/1234
   2. Open GitHub and create a new pull request
   3. Team convention for title: gitmoji issue title or good description #issue number
   4. Connect Github issue in the created PR after creation. (Successfully merging this pull request may close these issues.)
   5. Move the pull request to In Developer Review column.

5. Move the issue to the Developer Acceptance column in the Kanban board

   1. Wait for a code review from one of the team members
   2. Iterate your code until it is tech-approved ✅

6. Once "Developer Accptance" is done, merge your PR.

   1. Pre prod deploy will be initiated automatically.
   2. The issue corresponding to the PR will be closed and moved to "Release" column.

7. Verify your updates in Preprod to check nothing is broken. Ask PO to verify if needed.

Deploying to production

1. Run the deploy all websites/studios to prod script through GitHub Actions
   1. Deploying to PROD will move the cards from Release to Done
   2. Discussion is created automatically based on the issues moved from Release to Done
   3. Posting the release log link in the #envis Slack channel is done automatically.
      Note: Above automation only works for deploying to all webs, otherwise do these post release tasks manually. Max of 50 issues in the release column will be closed. (Think it serves the purpose for now)