fix: Add new release pipeline with production template

[v-viyada]

Details

Added new yml file for production release using production template and EnableSemanticRelease variable. Also moved the common code between CI and release pipeline to common template.

The new release pipeline will be added mseng ADO as it requires access to key vault for getting github and npm publish tokens.
To create pipeline in mseng ADO, yaml file should be available in main branch so I will create and test the new release pipeline after merging this PR.

Motivation

Context

Pull request checklist

• PR title respects Conventional Commits (starts with fix:, feat:, etc, and is suitable for user-facing release notes)
• PR contains no breaking changes, OR description of both PR and final merge commit starts with BREAKING CHANGE:
• [n/a] (if applicable) Addresses issue: #0000
• [n/a] Added relevant unit tests for your changes
• Ran yarn precheckin
• [n/a] Verified code coverage for the changes made

[DaveTryon]

Will this pipeline run on every commit (and we manually enable enableSemanticRelease when we want to release), or will this pipeline be manually triggered (and enableSemanticRelease defaults to true via the pipeline variables) ?

[v-viyada]

This pipeline will be CI disabled and will be triggered manually when we want to release. The default value is set to false for accidental manual trigger. So to do the release we manually trigger the pipeline and set the value to true.

[DaveTryon]

Is it possible that the official template would detect a blocking issue that the unofficial pipeline would not detect? If that answer is yes, then we should not release until after all official checks have completed. To my mind, the simplest answer is to decouple release from CI, which could take multiple forms:

1. CI enable the official build with release disabled. To release, we manually trigger the CI build at a validated SHA and with the release flag turned on
2. Move the publishing into a separate pipeline that consumes artifacts from the pipeline that uses the official template. The official template pipeline could be triggered either manually or on CI (I'd lean toward CI but it's not fully required)
3. It might be possible to move the release step into a job that runs only after the official pipeline completes successfully. This would require support from the templates and may or may not be something they would want to encourage

[v-viyada]

yes, official template runs extra sdl tools and can detect blocking issue which unofficial would not detect. I think we can go with option 1.

1. We can go with this option to keep CI enabled and manually trigger the build with release flag turned on. We do not require any further code change for this and enable the CI at pipeline level.
2. The release task do not consume any artifacts generated in CI pipeline. We are using semantic-release which takes care of everything. For release, we have to just run yarn semantic-release command. So creating separate release will not work well here.
3. We can try this but the release job will never run until we set the release flag to true manually. It does not make much difference between this and point#1 to me but this will require code changes and testing.

[v-viyada]

/azp run

[azure-pipelines]

Azure Pipelines failed to run 1 pipeline(s).

[DaveTryon]

Looks good on the assumption that we enable CI triggers for the official template (with enableSemanticRelease set to false), then we manually trigger the same pipeline (with enableSemanticRelease set to true) to trigger the release at a validated SHA

[ada-cat]

🎉 This PR is included in version 2.11.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀