This issue may need to be split in a separate issue per deployment target.
Some workflow decisions will need to be made before this goes into production. They probably all need to be tracked in their own issues:
A simple way initiate a release from GitHub is through the GitHub Releases process, which creates a tag. This is the opposite of our Travis CI pipeline deployments, which create a GitHub releases after a tag pipeline runs.
A more RELENG-specific method might be a manual event to trigger a RELENG-specific method that does both.
This would be a good point to implement deferred asset version bumps
This would allow CI to check for both SemVer correctness and RELENG requirements, without confusing the two
Which in turn would streamline normal development, as CI would no longer halt all important tests to insist on unnecessary/redundant version bumps before releases.
Decide how the pipeline should handle deployment failures, and how we would recover from them
Mechanism to deploy releases to PuppetForge