Our development and deployment process radically changed since we switched to Cloud and added more teams, and it is no longer “version number friendly.”
Don’t get us wrong - we are excited about each new release that we ship as much as we were in the past, and we want to share relevant details about them. What does require change is the format in which these updates are communicated.
What we changed
That does not help you a lot if you have a self-hosted version and get a release in the middle of the month, weeks after the previous recap. For that reason, as of December 2019, we’ll use a different release schedule for self-hosted releases. Each new release will be shipped right after the recap post, between the 5th and 10th of the month.
We’ll restrain ourselves from releasing new self-hosted builds in the middle of the month. If such releases do happen, there will be a strong reason for them, and they will be properly documented in the blog.
ActiveCollab Cloud accounts will keep on receiving updates as they did in the past - multiple times a day, with rollout schedules and plans tailored to stabilize deployed changes and user segmentation.
The previous paragraphs pretty much sum up the change of the release notes format. But feel free to continue reading if you are interested in learning more about our development and deployment process, as they influenced this decision greatly.
10+ Years of Release notes
ActiveCollab never had the official role of a Release Manager, but if there ever was one, I would have held it for the majority of the past 12+ years. When I put on a Release Manager “hat” and look back at these documents, I see two “eras”:
- The first was the time when we had only the self-hosted edition of the product, and
- The second is the period when the Cloud edition was the tip of the spear, with self-hosted lagging a bit behind.
There was no clean-cut between the two eras, but there is a visible shift between ActiveCollab 4 (when Cloud was introduced), and ActiveCollab 5. With version 4, the self-hosted edition was still dominant, and it controlled the scheduled release of the Cloud version as well. The releases were shipped with sequential version numbers, and an accompanying Cloud release followed the self-hosted release.
Cloud vs. Self-hosted
Cloud gave us much-needed flexibility to get better at delivering software. It let us release upgrades more often and target features in a better way to different groups of users. If any software problems arise, we can correct them in a timely fashion, sometimes before anyone noticed any issues in the first place.
What was new about version 5 release notes is they started to skip versions. At that time, we started building and shipping releases at least once a week, and not always to all users. Our deploy system supports three release targets (we call them “release channels”):
- Edge - only our test accounts, including accounts we use to manage the ActiveCollab development,
- Beta - teams that agreed to test experimental features before their official release,
- Stable - everyone else.
The team used Edge and Beta release channels to integrate software more often and to see how things fit together in production. Once everything was tested and stable, we would push it to the Stable channel and provide release notes of the changes made since the last stable release. We kept doing this for a couple of years, and it has served us well.
New people - new process
All this makes pinning a particular change to a particular version number hard, almost detective work. If I had to draw it, I would draw pre-Cloud release schedule as a single line where changes get integrated and deployed linearly:
Our new process can be depicted like this:
The first process does look simpler, and it’s how many people envision software delivery, Roadmap as a straight line.
On the other hand, many teams are turning to different processes to be able to deliver more value and compete in the marketplace. The process needs to allow space for experimentation, incremental rollouts of features and tests, selective availability of functionalities by demography, account age or usage patterns, etc. Such a roadmap looks more like a map, with different nodes and turning points, and less like a tunnel.
That’s a wrap!
The market is unforgiving, and our competitors are well funded, smart, and nimble. In such an environment, we need to get rid of practices that slow things down without providing substantial value and find smarter ways of working and delivering useful software.
A monthly release schedule for self-hosted builds and recap posts offer the necessary information to make an informed decision on whether to upgrade or not while letting us further adapt and evolve our processes. This way we’ll be able to build more useful software, faster.
