Skip to content

Release Process

Overview

This document outlines the process for releasing our software to production. We aim for weekly releases, focusing on small, frequent updates to minimize risk and deliver value to our users quickly.

Preparing for Release

  1. Ensure all desired features and fixes are merged into the main branch.
  2. Verify that all automated checks (tests, linting, etc.) are passing on the main branch.
  3. Review the commit history since the last release to understand what will be included.

Creating a Release Candidate

Our CI/CD pipeline automatically creates a release candidate when code is pushed to main. The process is as follows:

  1. A new tag is created with the format vX.Y.Z-rc.N (e.g., v1.2.3-rc.1).
  2. Docker images for backend and frontend are built and pushed to the registry.
  3. The release candidate is deployed to the staging environment.
  4. A draft GitHub release is created.

Testing and Validation in Staging

  1. Perform a sanity check on the staging environment:
  2. Verify core functionalities are working as expected.
  3. Check for any obvious regressions or issues.
  4. If issues are found:
  5. Create tickets for any new issues discovered.
  6. Fix critical issues immediately and create a new release candidate.
  7. For non-critical issues, decide whether to fix before release or include in the next release cycle.

Promoting to Production

Once the release candidate is validated in staging, initiate the production release:

  1. Go to the GitHub repository and locate the draft release created by the CI/CD pipeline.
  2. Click the Edit button.
  3. Review the automatically generated release notes are correct.
  4. Edit the rc tag by removing the -rc.N suffix and create a new tag with the format vX.Y.Z.
  5. Uncheck the "Set as a pre-release" checkbox.
  6. Check the "Set as the latest release" checkbox.
  7. Click the "Publish release" button.

The production release workflow will:

  1. Pull the Docker images tagged with the release candidate version.
  2. Run database migrations.
  3. Deploy the new version to production Cloud Run services.

Post-Release Activities

  1. Perform a sanity check on the production environment:
  2. Verify that the deployment was successful.
  3. Check core functionalities to ensure they're working as expected.
  4. Monitor for any unexpected issues or errors.
  5. Notify the team on Slack about the release.
  6. Update Featurebase with the product updates based on the commit messages included in this release.

Rollback Procedure

Currently, we do not have an automated rollback process. If a critical issue is discovered in production:

  1. Manually revert the database to the previous state if necessary.
  2. Manually redeploy the previous version of the application to Cloud Run.
  3. Update the team and users about the issue and the rollback.
  4. Investigate the root cause and implement fixes before attempting another release.

Best Practices

  • Keep releases small and frequent to minimize risk.
  • Ensure all code being released has been properly reviewed and tested.
  • Write clear, descriptive commit messages to facilitate easy understanding of what's included in each release.
  • Regularly review and improve the release process based on team feedback and lessons learned.

References