Release Process

Creating and shipping Steeltoe releases

Due to breaking changes between release lines, portions of this document will not apply to release lines prior to 4.0.0.

Read this page in full before taking action.

Important

All deployments to NuGet.org require manual approval by a senior member of the Steeltoe team.

NuGet package creation and publishing

All Steeltoe packages are produced by CI pipelines. This GitHub Actions workflow is used for building and releasing packages.

• Depending on how the workflow is triggered, packages may be signed, deployed to the Steeltoe Azure Artifacts feed, and/or deployed to NuGet.org.

Release-time checklist

1. In Steeltoe:

   • Run public-api-mark-shipped.ps1 to update PublicAPI.*.txt files.
   • Update the VersionPrefix in shared-package.props.
   • Create a new GitHub release with a tag that matches the VersionPrefix (pushes to NuGet.org).
   • Update the Release support matrix.

2. In Schema:

   • Ensure schema.json is up to date by running its tests twice (first run creates pending changes).
   • If changed, create/push a git tag and copy the latest schema to Documentation.

3. In Documentation:

   • Check for references to github.com/SteeltoeOSS/Steeltoe and ensure all links point to the proper branches.
   • Create/push a git tag.
   • Use the stage-prod-swap GitHub Actions workflow to swap the staging slot into production (https://www.steeltoe.io/).

4. In NetCoreToolTemplates:

   • Update active/default Steeltoe versions in .template.config.
   • Update Steeltoe versions used in tests by editing SteeltoeVersion.cs and TemplateOptions.cs‎.
   • Bump the VersionPrefix.
   • Create a new GitHub release with a tag that matches the VersionPrefix (pushes to NuGet.org).

5. In NetCoreToolService:

   • If NetCoreToolTemplates was released, a new build/deployment is required because templates are embedded within the container image.

6. In InitializrService:

   • A new build/deployment is only required if anything has changed since the last deployment.

7. In InitializrWeb:

   • A new build/deployment is only required if anything has changed since the last deployment.

8. In InitializrConfig

   • Update the active/default Steeltoe versions in SteeltoeInitializr-Staging.yaml.

9. After sanity check at start-staging.steeltoe.io:

   • Use the stage-prod-swap GitHub Actions workflows on NetCoreToolService/InitializrService/InitializrWeb as needed to swap the staging slot into production (https://start.steeltoe.io/).
   • Replicate changes from SteeltoeInitializr-Staging.yaml to SteeltoeInitializr-Production.yaml in InitializrConfig.

10. In Steeltoe:

    • Open a pull request to merge changes back into long-lived branches, such as 3.x and 4.x. Check for references to github.com/SteeltoeOSS/Steeltoe and ensure all links point to the proper branches.

11. In Samples:

    • Open a pull request to merge changes back into long-lived branches, such as 3.x and 4.x. Check for references to github.com/SteeltoeOSS/Steeltoe and ensure all links point to the proper branches.

Tip

After each stage-prod-swap workflow run, consider using the corresponding Build and stage workflow to overwrite the retired production site (which was demoted to the staging slot) once the new version is confirmed stable.