As you might know, at Tuist we are obsessed with streamlining development workflows, and that applies equally to your workflows and ours. One of those workflows that has been bugging us for some time is the release process. When you or we opened PRs making fixes or improvements to the CLI, you had to wait for someone from our team to kick off a new release. Annoying, I know… But luckily, not anymore.
We’ve introduced a release pattern that we’ve already adopted in other open source repositories. We call it continuous releasing. The idea is simple: PRs are required to follow conventional commits. For example, if it’s a new feature for the CLI, the PR title should start with feat(cli). On merge, we run git cliff to determine if there are releasable changes, and if there are, we trigger the release automatically. We do the same for the macOS app and the server, which we tag and push to the Docker registry for organizations with a license to self-host it.
A few things I’d like to call out:
- We can’t continuously release the iOS app, but we push the builds to TestFlight for later release. One of us still needs to get involved to take some extra manual steps there.
- The server changes are continuously deployed to our hosted instance, so you’ll always be using our latest version.
You can read more about the continuous release pattern here.
We couldn’t be more excited about this because it means we can redirect the energy that would go into coordinating and executing releases into building solutions for your needs.