Release Workflow#

This page describes how to make releases of the software within the imap_processing and sds-data-manager repositories, and the steps needed to push said software to the production environment and update the data products.

Software Releases#

This project uses a workflow in which releases are made off of a ‘version branch’ (e.g. v0.1.x), as depicted in the diagram shown in the git & GitHub Workflow page. This includes both ‘nominal releases’ (i.e. new features to be released to the public) and ‘patches’ (i.e. bug fixes to the version branch). These workflows are described below. It is assumed that steps (1) through (4) in the git & GitHub Workflow are already completed.

Note: We use the ``imap_processing`` repository as an example here, but this can be applied to ``sds-data-manager`` as well.

Nominal releases#

  1. Make sure the dev branch is up-to-date with any changes you want included in the release (i.e. merge in any feature branches using the nominal git & GitHub Workflow).

  2. Create a new version branch off of dev. The name of the branch should match the version number to be used for the release, which should follow the software versioning conventions. The patch number should be marked with a x, and the name should be prepended with v (e.g. v0.1.x).

  3. Make any release-specific commits to the new version branch using the nominal git add/git commit cycle. This may include commits that add release notes, or update version numbers in various configurations.

  4. Push the version branch to the main IMAP-Science-Operations-Center imap_processing repo (i.e. upstream).

  5. Create a new release, using the version branch as the Target branch. Assign a new tag with the specific version number, including the patch number (e.g. v0.1.0).

  6. In GitHub, create a pull request that merges the version branch into dev. Proceed with the nominal review & merge process described in steps (10) and (11) in the git & GitHub Workflow section.

Patches#

This workflow assumes that a version branch has already been created (and released at least once) for the minor version which you want to patch (e.g. v0.1.x).

  1. Create a new branch off of the version branch that you want to patch (hereby called the ‘bug-fix branch’). Commit any relevant bug fixes to this bug-fix branch using the nominal git add/git commit cycle.

  2. Create a new pull request that merges the bug-fix branch into the version branch. Proceed with the nominal review & merge process described in steps (10) and (11) in the git & GitHub Workflow section.

  3. Once the changes are merged into the version branch, create a new release, using the version branch as the Target branch. Assign a new tag with the specific version number that increases the patch number by one from the most recent tag (e.g. v0.1.1).

  4. In GitHub, create a pull request that merges the version branch into dev. Proceed with the nominal review & merge process described in steps (10) and (11) in the git & GitHub Workflow section.

Deployment#

Once a release is created in GitHub, a SDC dev team member can follow the CDK deployment steps to deploy the software to AWS. Once the software is deployed, a user should be able to call the APIs.

On this page
Show Source