As you likely know by now, v7 of Snipe-IT dropped a few weeks ago. Those of you who have been with us for a long time know that those major version releases can be pretty tough. When you’re hoisting the underlying framework by several versions, upgrading dependencies, plus adding features, things can get messy fast. Making sure that we cover as many possible versions as possible for our community users is an entire journey, but it’s also really important to us.
I can pretty confidently say that v7 has been our smoothest rollout in the 13 year history of Snipe-IT. We just released v7.0.7 today and have issued several small releases over the past few weeks, but not because we had to. We had a small fire here or there the day of release, but all of the subsequent releases have been minor fixes or improvements surfaced by the community for their own unique hosting environments.
So how did we get here?
This was a long-planned, careful release. In the process of building out v7, we also doubled our efforts to make sure we had a much more comprehensive automated test suite than we had before. This gave us a lot more confidence for this release, and that’s a huge hat tip to both our internal developers and also the community members who added tests.
Version 7 was late. Much later than I would have liked. But we also won’t release our software until it’s ready. The original plan was Oct/Nov 2023. We were almost ready, but we caught something last minute that we had to fix before we could release it. Then the holidays, vacation schedules, a few staffers got sick, etc. Normal life stuff.
We’re a small team, and overwhelmingly, that works to our advantage. It’s hard to move big ships. With a small team, we can iterate quickly, release often, and listen to our users more closely. With major releases, that agility only goes so far, since we have to consider not just our hosted customers, but also that one weirdo (you know who you are) who runs Snipe-IT on a raspberry pi in the middle drawer of their desk.
We have to plan for and mitigate uses cases we don’t even know about yet. What’s their upgrade path going to be? What version might they be upgrading from? How many hundreds of release notes will they have skimmed past? Our hosted servers are known quantities. Our platform was ready back in November. We were ready for us, but we needed to make sure the rest of the community was too.
Asking those questions and trying to solve them preemptively is partially due to our relentless dedication to releasing a top-tier product that we can all be incredibly proud of, but there are slightly more day-to-day practical reasons as well. Any support ticket we can prevent, any Github Issue or Discord conversation we don’t have to have is a win, so we try like hell to predict as much as we can. The smoother we make life for you, the smoother life is for us.
While we likely could have released at half-staff, I always prefer to be cautious. We are a belt-and-suspenders type of shop. We manage data for several Fortune 500 companies (and those are just the ones we know about.) We take that responsibility very, very seriously and I’ll always pick late over wrong, every time, without exception.
This is all made slightly more difficult because we are open source. Sometimes a big PR comes in from the community for a feature that wasn’t internally planned for the release, but it’s so good, we have to take it. That creates an additional round of QA, likely some small UI tweaks, etc.
We believe that software can be feature-driven or date-driven, never both. We are not date-driven here. Software quality and employee work-life balance are absolutely critical to us. If that means the software is a little later than we had hoped, that’s how it goes – especially because we knew v7 wasn’t going to have a single “killer feature” out of the gate. v7 was (and is) a largely utilitarian upgrade to bring the Snipe-IT supported versions of PHP in alignment with LTS and modern PHP versions, and also to position us to make some of those bigger swings we’ve been wanting to make.
What Worked: Merge Often
Long-lived disparate branches can be really hard to maintain. We had a v7 branch, but were also pushing fixes to v6, which was on the develop branch. Some of the larger lifts we had to make meant huge chunks of code changed, and there wasn’t always going to be an easy merge path without being in conflict hell forever. We’ve been there before. This time, we made sure to constantly, consistently merge develop back down into the v7 branch to keep the distance between them as small as possible. Small? No. But weekly merges back meant an easier time of handling the merge conflicts we knew were definitely going to come up. Three merge conflicts are much easier to handle than three hundred.
When it came launch time, Brady merged v7 one last time into develop, and then I merged develop into master and tagged it with the release notes. ZERO merge conflicts outside of the one we always have in our version file.
Big version launches are stressful as hell, and by being vigilant about keeping those diffs between them as small as we possibly could, it meant the Big Day had no unexpected conflicts. It went…. smoothly. Almost eerily so. But that didn’t happen by magic, That was months of diligence and it paid off a thousand times over.
What Worked: Rollbar
I talk about Rollbar in every conference I speak at. I swear they don’t pay me, and maybe you don’t use Rollbar but instead some other real-time error monitoring system. 19 minutes after we tagged v7, we tagged v7.0.1 – and while that part sucks, 19 minutes is better than several days or weeks. That’s because Rollbar on our demos is the canary in our coal mine. People are constantly interacting with the demos, sometimes even in ways they shouldn’t be, but the ability to see an error, reproduce it locally, and immediately patch it has been one of our superpowers for a long time. Use Rollbar, use whoever you like, but this part was pivotal.
What Didn’t Work: The Inside Baseball
We of course had an internal developer retrospective after v7 launched. We had a list of things we thought we did well and a list of things we think we could have done better. We didn’t give the developers our list, but instead asked them (with the usual caveats, no wrong answers, etc.) what they thought.
There was good news and bad news. The good news – everything they came up with was on our list, which means our heads and hearts were largely in lock-step for what worked well and the more obvious stuff that we could improve on.
The bad news – and it was hard to hear, but pretty unanimous among the team – was that myself and the release manager could have – should have – done a much better job of communicating with the team. We had told them it was going to be that Monday, but we didn’t specify a time. Our dev team spreads across many timezones. We tagged v7 at 10AM Lisbon time, (5AM for half the team, 2AM PST for most of the rest), thinking it would be better if they could wake up and know nothing was on fire. They had already worked so hard on this, and we’re not really a “crunch time” kind of company.
While I was trying to spare them the stress of setting a 4AM alarm for launch time, what I didn’t realize is that I robbed them of agency and I robbed them of the feeling of accomplishment for a hard-fought launch. In trying to spare them what I had gone through in the software industry, I also stole from them the camaraderie of a group effort being made real.
That is a mistake I won’t make again, and I’m incredibly grateful to have a team where hard conversations can happen.
TL;DR
This release went really, really well, and we have so many folks – internally and within the Snipe-IT community – to thank for that.
We hope you like v7. We worked really hard on it and are very proud! But perhaps more importantly, I hope you take from this that even the best intentions within the best companies can end up hurting the team if you don’t communicate with them properly.
