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. Create a Pull Request

   1. git push origin fer/1234
   2. Open GitHub and create a new pull request

3. Move the issue to the Technical Review 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 ✅

4. Deploy your changes to staging for external approval

   1. In your local environment, checkout the staging branch and pull the latest changes
      1. git checkout staging && git pull
   2. 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 will be triggered automatically

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

   1. Wait for external review
   2. If external review is APPROVED ✅
      1. Rebase and Merge the Pull Request to the main branch
      2. Deployment to pre-prod will be triggered automatically
   3. If external review is NOT APPROVED ❌
      1. Go back to step 3.2. (Iterate your code until it is tech-approved)

6. Move the issue to the Deploy column in the Kanban board, and add the "Ready to Deploy" label

Deploying to production

1. Run the deploy all websites/studio to prod script through GitHub Actions

   1. Create a Release log in GitHub discussions
   2. Post the release log link in the #envis channel on Slack

2. Close issues tagged with the label "ready to deploy"