Part 4: Automating Releases

As developers we should be looking to automate as much as we can. Setting SemVer values is certainly one we should do. One reason is to reduce how much we have to remember for regular tasks, another is removing emotion from versioning. Check out this video for some other nifty reasons. It is pretty straightforward to set up.

First let’s install it globally.

$ npm install -g semantic-release-cli

Now that it is installed we can run through a nice little wizard to configure it. Making sure you are in your module folder type:

$ semantic-release-cli setup

There are several prompts:

• Whether your GitHub repository is public or private
• Which NPM registry you want to use (Default: http://ift.tt/1bx8DsD)
• Your NPM username (unless passwords were previously saved to keychain)
• Your NPM email
• Your NPM password
• Your GitHub username
• Your GitHub password (unless passwords were previously saved to keychain)
• Which continuous integration system you want to use. (Options: Travis CI / Pro / Enterprise, or Other)
• Whether you want to test a single node.js version (e.g. — 0.12) or multiple node.js versions (e.g. — 0.10, 0.12, etc.)

Enter your information, most of them will default to the right one, just make sure for the CI question that Travis-CI is chosen and for the node version select single node.

Let’s see what happened! Looking at package.json we see a new script semantic-release.

"semantic-release": "semantic-release pre && npm publish && semantic-release post"

Also notice that the version section of package.json has vanished. Travis-CI will handle that now, however to suppress a warning message when we release the npm package let’s add it back in as:

"version": "0.0.0-semantically-released"

It also updates the url to https and adds semantic-release to the dev dependencies. Let’s configure travis.yml a little by adding our test script in the chain, between before: and after: add:

Script:
        - npm run test

This will make sure that our tests are run when our CI attempts to publish them.

To learn more head over to the modules readme here.

Being a good Commitizen

Let’s install commitizen to help us keep our commit messages consistent in order to help our versioning system to be even more emotionally agnostic.

In your terminal run:

$ npm i -D commitizen

Next we need to tell it which standard to follow for our messages. I go with a fairly standard one used by the AngularJS team called… conventional changelog!

You can read more about it here.

To install it simply type:

$ npm i -D cz-conventional-changelog

If you are pretty settled on these then you can install them with -g instead of -D. If you do that there is a bit more setup involved. Go here for more info.

This adds bin to node-modules for us to use in our npm scripts called git-cz. You could just run the following instead of git commit:

$ git cz

You can use all the git commit options with git cz, for example:
git cz -a.

However we are going to set up a script in our package.json to make things a little cleaner and a bit more obvious. Simply add a new script with the following:

"commit": "git-cz"

Then we need to tell it to use our cz-conventional-changelog, in the config section (create one if you don’t have one) add:

"config": {
    "commitizen": {
        "path": "node_modules/cz-conventional-changelog"
    }
  },

Let’s stage these changes.

$ git status
$ git add -A
$ git status

Before we run our new nifty script head over to your repo on github and create an issue. For this let’s make it something like “standardize commit messages”. This is probably your first issue, however if it is not take note of the number and use that for the final prompt.

Now that everything is staged we can run (on the last prompt put closes #1):

$ npm run commit

Automatically Releasing with Travis-CI

$ git status
$ git push

Look at the repo and notice the closed issue. Go to http://ift.tt/2cmaXK5 notice the problem? It is stuck at the testing phase. This is because we have a -w on our test command so it will never close. To fix this we are going to add a script to our package.json:

“test:single”: “mocha src/index.test.js”

We also need to edit .travis.yml and change our npm run call:

- npm run test:single

Go back to travis-ci.org and cancel the build.

Let’s try that again in your console:

$ git status
$ git add .
$ npm run commit

Now watch travis-ci, note the version number change. Look at github release, look at npm see how the version change has propagated across the multiple distributions. We are cooking with gas now!

Next… Automating Testing and Code Coverage!

Key:

= Time Saving Idea

= Pro Tip

= Note

= Alert

= Code Update

= A Closer Look

Originally published on Wordpress