🛤️ tracking: Release Automation

[runspired]

The EmberData team recently landed a number of improvements to the release publishing and CI pipelines to reduce the cost overhead of releases, enable publishing canary builds to npm, and prepare for a more automated future.

This ticket outlines remaining work items we hope to accomplish to complete our quest for low-to-zero-overhead releases:

CI

• ensure we match Travis for current Azure setup
  🔒Claimed by @HeroicEric Update Azure Pipelines config to match Travis config #6098
• Drop travis.yml and deactivate Travis for ember-data We dropped all jobs we could. Once we have allowed-failure equivalent in gh-actions we will drop the rest.
• validate that all PRs have a label for the targeted branch
• validate that all PRs have a label for their kind (fix|chore|test|security etc.)

Branch Management

• document how to use the backporting bot feature for backporting fixes to beta and release branches
• improve backporting bot feature to account for fixes that need to target both beta and release branches
• configure the backporting bot to work via labels
• [DISCUSS] backporting bot should run lint --fix automatically on backported commits

Changelog Generation

• move to lerna changelog from custom solution
• add changelog generation into the lerna version automation step in our release script
• investigate configuring our monorepo to publish release notes (possible if using lerna changelog)
• Improve Changelog generated output (ref Better changelog management #7928)
  • don't include beta/canary builds
  • don't include references to private/unpublished packages

Publishing

• Automate nightly publishing of canary to npm registry
  • failed & successful attempts should notify @core-data in #dev-ember-data on discord
  • should only publish if changes exist since last canary
• configure CI with a token to be used in place of OTP for publishing to npm
• upgrade release script to confirm or bypass the lerna version prompt for the intended version bump

Testing
Automation also means we will want to ensure more robust testing.

• add tests for our automated release process (likely via https://verdaccio.org/)
• IE11 integration tests [FEAT CI] Fastboot and IE11 Integration Tests #6431
• fastboot integration tests [FEAT CI] Fastboot and IE11 Integration Tests #6431
• make it clear upstream needs to be set
• lts release bumps patch version when it's just a "new channel", is this necessary?
• update guidance for using lerna-changelog always, not just lts
• lerna-changelog generates for every alpha, this is annoying, can we auto-collapse to minor/major?
• should we drop internal/house commits?
• we should update azure-pipelines ember-try guidance to reference github actions
• can we automate the changelog step further?
• can we auto publish release notes?

[runspired]

cc @HeroicEric for assignment

[BryanCrotaz]

I looked at whether I could contribute on backport bot but it appears to backport onto branches - There are no release branches since 3.4 - is this a change of branching methodology?

[runspired]

@BryanCrotaz we only create specific release branch if we have something to backport, so the first backport we create a branch from the tag.

[runspired]

@BryanCrotaz would you be interested in picking up where @Gaurav0 left off with the backport bot?

[runspired]

with #9231 I don't think this particular ticket serves us much use anymore. I would love for use to get a backport bot still, but automating releases is itself a big enough win I'm not sure its worth keeping this open.