I’m happy to announce that we’ve released a first open source version of kaeter:
it’s a CLI tool that aims at helping in codebases and repositories that contain a lot of deployables or deliverables such as:
- jars
- packages
- docker containers
- binaries
- arbitrary tar balls
- … and anything that can be released
It tries to do so in a sufficiently generic way to support most, if not all, kinds of releasable artifacts.
In A Nutshell
Essentially, kaeter helps you answer both of these questions:
How do I release this and what is the next version number?
To the project maintainer, it provides a way to describe the build, test and release steps.
To a project developper, it provides a simple interface to release and version things.
As a bonus, it also provides a CI/Build-Engineering team with a means of doing release review.
Finally, it keeps track of the commit id’s that went into cooking a release.
Motivations
The tool is born out of a latent frustration around a fundamental fact of our consulting work: over time, many different people work on a variety of projects, with no project being really similar to any other one.
With practices evolving rather quickly and only few resources available to clean up and standardize things, the time to hand over a code base or restart a work iteration was too high.
kaeter does not solve every issue here, but helps immensely for fix and ship scenarios where our customer comes with an urgent and small request on a project no one has touched for months.
In parallel, we were building a fat repo containing various utilities, and essentially ran into similar issues of how the hell do I release my changes on tools we barely knew.
Usage
kaeter enables you to do declarative releases, that is, it allows anyone to ask please release artifact X. Optionally, you may also ask for a major or a minor release, if you are using semantic versioning.
All it asks from you, is to have a Makefile with the respective build, test and release targets.
More details available on kaeter’s repository.
Historical notes
kaeter’s initial version goes back to two years ago at Sqooba. It was written in Python and focused more on helping with versioning maven artifacts in a declarative way. It was also pretty buggy.
To make our lives easier while wearing our build engineering hats at Open Systems, we rewrote it in Go and dropped the maven-specific features.
Remaining Work
Currently, kaeter release will use the current state of the working copy to build/test/release an artifact. Ie, it won’t checkout the commit referenced by the version being released.
This is not too much of a problem but could lead to issues if additional changes are sandwiched between the commit you want to release and the commit that contains the release plan.
This should be addressed at some point, as well as some improvements of the documentation :).