Developing and testing is only one part of the art of creating software. Another part is shipping the artifact. 🚢

Delivering software requires some steps; we need to run tests, build our artifact and publish or deploy it somewhere. Most often, those steps are executed in a pipeline.

A pipeline is a way to automate all the required steps. Therefore tooling and CI servers with the necessary configuration are needed.

A lot of companies have a complicated setup and need whole teams to maintain such a platform.

Wow! 😮 That sounds complicated. “Maybe it’s better to forgo about CI and pipelines. I do everything manually” is probably what you think right now.

But no! Thanks to the great landscape of existing tools out there it is not that complicated!

Benefits of automatic releasing

Before we have a look at how to set up our pipeline with automatic releasing, let’s first clarify why it’s important.

Usually, a release, if it is done properly, causes a bunch of things.

We generate a CHANGELOG.md for people to see the changes made between releases.

for people to see the changes made between releases. We generate a release in our project. This release contains the release notes and the artifact.

We tag our master branch. Tags allow us to hop back to the released version easily.

We bump the version in our package.json so that it matches the released version.

so that it matches the released version. We publish the artifact to npm . Before a publish we build and test the artifact.

Summarized, there are a lot of manual steps needed. Humans should devote their time for more important things than executing the same mundane task over and over again. All of the steps above can be automated! 🤖

Another advantage of automizing the steps above is that it gets much more comfortable to continuously deliver software once the number of contributors to your project grows.

You don’t have to worry about the release process. All you need to do is to check and merge pull requests!

Conventional commits

With a growing number of contributors, we need to make use of some standards that every developer follows. Standards help in easier automatization and keeping the commit history clean and descriptive.

Using meaningful and well-structured commit messages in a consistent way are crucial to all software projects. They make your project clearer and more accessible to new contributors and ease the forensic process of understanding what changed.

Conventional commits introduce a standard on how your commit messages should be structured.

The conventional commits specification is a common standard for adding human and machine readable meaning to commit messages

A conventional commit contains the following format.