Automating the release process

Our current release process involves a few manual steps which could be automated away. I’m hoping that having less manual tasks will allow us to release more frequently and ship code to users quicker.

Back when I joined the team there was a cycle of roughly 1 release per quarter, which we managed to get down to a release every 1-2 weeks (depending on the amount of changes). This is a substantial improvement and it’s something I’m proud of the team that we were able to do that 👍

Despite that, cutting a release usually takes around 30-60min which is more than I’d like. I’m confident that we make that a lot less time consuming. This is complicated by having 2 release lines (8.x + 10.x), where one needs to be careful to empty the dist folders when switching between them. For this reason I have 2 separate checkouts locally, but that’s obviously more of a workaround rather than a long term solution.

Long term goal

Ideally we should have either a button or a git tag trigger a release. On top of that it would be desirable to have a canary pipeline which publishes to preact@next and is triggered when a PR is merged into master. That way users that are highly dependent on a specific PR in master can immediately benefit from the latest changes at the slight risk of running into bugs.

Current process

Let’s look at the status quo, to have a better grasp of the necessary steps:

1. Checkout master or 8 branch
2. Ensure all old build artifacts are deleted
3. Run npm run build
4. Publish via npm publish
5. Grab changelog via changelogged (should be automated!!)
6. Create release + tag via GitHub’s UI

Should we stay with TravisCI?

Initially I planned to play around with GitHub’s new Action feature over the coming weekend, but there are costs associated with it, if we’d go that route. Right now the free plan has 3000 free minutes and our average build time is 3 min. With a rough approximation this would result in having an average of 10 builds per day. Right now we fall into that category, but I do expect us to continue to grow like we did in the past 2 months. Paying per user would very likely blow past our available budget.

So overall I’m leaning towards staying with Travis, although I do like the GH Actions UI more.

EDIT: My math was way off, it’s approx. 30 builds per day which is totally fine.

Preact user account

We already have a preact user account that is theoretically able to publish packages to npm. @developit had a lot of foresight in the earlier days of Preact and registered it. We could leverage those for our automation task.

Next steps (in no particular order)

• Add option to pass GH token via an argument to changelogged
• Figure out the Travis yaml syntax for listening on specific branches for specific tags
• Adding the necessary secrets
• …

There’s probably more to it, but I need to be elsewhere now. I’ll update this post as more things come to mind.

[developit]

@marvinhagemeister I have a working SauceLabs setup in GA here:

https://github.com/babel/preset-modules/blob/master/.github/workflows/main.yml

[sventschui]

GitHub Actions are free for public repos, no limits. Thus no math needed @marvinhagemeister 😉