Releases that adapt to your desired speed | Toucan Toco

Overtime, we’ve gathered a lot of different feedbacks from different types of users about our release process. These feedbacks are very precious to us. They are guiding our every-day actions and sometimes inititate bigger changes. This article tells the story of one of the latter.

Some of you install the Toucan Toco platform on-premise. In that case, deployment and maintenance often happens in very constrained environment, with many validation steps. Upgrading is not as easy as the automatic processes we’re used to in the web world.

Moreover, you sometimes cope with users who are not used to changing products. They prefer stability over new features, and do not want to see changes from one week to the next.

That’s why we decided to clarify our release schedule and adapt it to your need, while keeping our fast and agile habits. From now on, we’ll produce two types of releases:

• weekly releases: they contain the last improvements and fixes in the product, and are out every thursday
• monthly releases: they accumulate the changes of 4 development weeks, and are battle-tested against complex apps during their last week of production

We’ll indicate which version corresponds to which release type in our releases notes. On our package download webpage, you’ll note that we will publish a latest-weekly package and a latest-monthly package.

And what about critical fixes and security updates?

For very important stuff that can’t wait a month or even a week to be published, we’ll patch both the latest weekly and monthly release. It means a bit more maintenance work for us, but it ensures Toucan Toco platform stays perfectly secure anytime.

I’m not an on-premise customer but a cloud one. Does that changes anything for me?

No, on our cloud instance, we manage Toucan Toco platform for you. By default, we update our cloud instances every week, following the weekly releases.

But if you feel weekly updates are a bit too much for you and your users, we can switch your instance to the monthly release. Keep in mind that you’ll have to wait up to 3 weeks to get the latests hot stuff you are reading about in our weekly newsletter ;)

I’m a developer, and I’d like to know more about the underlying process!

This change is reflected on our git workflow and branching model. We were following a usual develop/master scheme, enhanced with an intermediary beta branch that we used to produce pre-releases.

When we started to do releases at a regular time interval, we wired our master branch to our monthly releases and our beta branch to our weekly ones. This, of course, was not visible to package users. As package names and what was inside diverged it caused confusion. We considered using the names stable and beta, before realizing they were very generic and not reflecting our regular release schedule.

We now have:

• a master branch, on which we merge our current developments
• a branch for every release cycle (weekly, monthly)
• and pre-releases branches to test, qualify and eventually make some fixes (weekly-candidate, monthly-candidate)

Each cycle, we update the appropriate candiate branch with master, test it, and promote it to the release branch with a tag when it is ready. From there, our packaging process takes over, uploads the release for our clients to download or deploy it to our cloud instances.