Intuit/Auto for Automating Release Workflow — Part 1

Managing releases has never been this easy!

Release management might seems trivial at first, but it is certainly one of the things we’d wish we started from the beginning of our project, or at least i did 😱.

Managing releases should at least consists of these activities:

  • Managing change log
  • Managing releases: canary, pre-release, and latest build.

Why intuit/auto?

While there are a couple of tools we can use to automate above activities, intuit/auto is powered by pull requests, something we’d surely expect to be used in a project involving team of developers or contributors 😀. So the overhead of implementing this automation is expected to be minimum.

Setting Up intuit/auto

For the sake of simplicity, we will be implementing intuit/auto in a Javascript project on Github. It can be our existing project, or we can just simply create a new one.

First, install auto in our project as devDependencies. We surely can use npx auto to run all of its command without having to install it locally. I pretty much prefer installing it locally since it helps in reducing my CI runner run time, since the intuit/auto package should’ve existed in the cached node_modules for subsequent runs. More on this later.

Then, add auto into the script block in `package.json`.

Verify above script by running yarn auto -- -V. It should outputs our newly installed package version.

Init auto by running yarn auto -- init. It would then prompt us to choose which package manager we are using. Let’s choose Git Tag for this, since we won’t be publishing our project to the NPM repository.

It would then show what plugins we’d like to use. While we can install this later, i choose to use the Released plugin. This plugin would automatically label the merged and released pull requests with released.

Enter our Github repository address.

Enter our Github username and email we’d like to use for this project. This is what we usually do using git config user.name and git config user.email in each of our project.

Now, we have to choose whether to make a release only if the corresponding pull requests have a release label. I choose not to use this, assuming that each pull request is a single buildable change, so each should have its release. Aside from that, we can use the skip-release label to not make a release for specific pull request. More on this later.

Now, if we already have an .env file at the root of our project, which is the same directory with where package.json resides, we can skip below step.

As for the labels, we can skip this one for now.

The CLI should’ve stopped prompting us at this point. But wait, there’s more. While we have chosen to use Git Tag for our package manager, intuit/auto CLI doesn’t actually install this plugin for us. So, before further steps, let’s install the needed package for this.

Voila! That’s an easy one!. intuit/auto is now setup and configured in our project. We can visit our project folder and check for .autorc .

Remember the create labels prompt?. intuit/auto has a predefined set of labels under the hood, consisting of major, minor, patch, prerelease, and many others. If we are certain to use these labels for our pull requests, we can run yarn auto -- create-labels .

Warning: this would create and/or mutated the labels on our Github repository.

We can then visit our repository to see our newly created labels.

Next…

Now, that intuit/auto is setup and configured in our project, this is the time for us to make some pull requests! 😀

We’ll be looking into how our pull requests play a part on this automated release workflow in the next part of this series. Stay tuned! 🤓

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store