Improving The Doras Development Cycle

We’ve been hot and heavy pushing new micro-releases to Doras since the Beat launch on February 3rd, and it’s time we come up with an actual plan to give you meaningful updates. As our Admiral of the Fleet, I feel like it’s my duty to step in as a Project Manager to outline some issues we’ve faced in our development cycle, and to give you some insight to our DevOps.

How we handle things currently

Right now it’s pretty straight forward. When we get a report via Discord or Ticket be it a feature request or bug report, we create an issue in our tracking software Linear. We use Linear as our code is hosted on GitHub and it makes it super easy to integrate and track. We’ll manually set a priority and tags depending on the issue, and either start working on it straight away, or leave it there until we’re ready to work on the task.

Once we’ve completed the issue, we give our package.json file a version bump, merge the code from whatever branch into the main branch, approve the pull request, wait for Vercel to deploy the latest, manually go in and create a new release on GitHub to do the version bump and generate the release notes which then publish the release that automatically posts it to our Discord. That’s a lot of work for a micro release.

It makes our releases frequent and hard to keep track of, and doesn’t provide us a good way to keep a static changelog and track what might be sitting around a while.

The problem cycles can solve

I’m a sucker for productivity and stats, but I also hate micromanagement. If there’s a feature request that we just don’t want to sink copious amount of time into that only one person asked for, it’s ok for that to go onto a backburner. If you know me, I’m always looking for ways to improve productivity and things in general. I’m the type of guy who’d build something for 10 hours to save 5 minutes.

We’ve tried GitHub Projects, Linear, Notion, Mattermost, Plane, the list goes on and on. Integration with GitHub is most important as it’s where our code and continuous integration lives, so it’s vital. Also as a big GitHub Nerd, I simply love it. I also work at GitHub in my “real life job”, so I know the ins and outs pretty well.

So we settled at the moment on Linear, using their Cycles feature. This allows some pretty sweet things such as:

• All issues created are put into the current cycle
• Any issue not completed before the deadline is auto put into the next cycle

So.. How will the releases look after this?

TL;DR, no more micro releases and multiple of them in a given day. For example, on February 10th we released v0.1.8, v0.1.9 and v0.1.10, two of which were within an hour window of each other. Now, our current cycles are set for every two weeks going forward. Every merge of a feature or improvement we do will go into a dedicated branch for the cycle. When the cycle is over, we’ll merge that branch with main, with all the new features attached.

This of course wouldn’t affect any bug fixes and hotfixes that need to be instantly deployed. Anything that’s instant will just be straight deployed once we can confirm it fixes the bug. It won’t make a new release either un less it’s needed.

Continuing CI/CD

For now, our deployments are auto built when we commit to the main branch. We don’t have a way to automate the new cycle branch creation, merging or releases, however it’s not too much hassle as a manual job that needs to be done every few weeks. We will however continue to look into ways we can improve this.

I’d love to hear from folks who’ve experience in this kind of environment and to help shed some light on how they handle things. Do folks usually manually update their package.json and create branches for cycles? How do they handle releases? I’m curious and would love to start a discussion on it and the tools available to help teams with this sort of thing!