Blog

Shipping fast, shipping small - how Gearset releases in vertical slices

Oli Lane on October 29th 2020

There are lots of approaches to delivering new versions of software. You can release big bundles of features all at the same time as a whole new version. Alternatively, you can release individual features one at a time, and not worry too much about version numbers. Or you can go even further by releasing features in multiple slices, iterating as you go. As with everything in software development, all of these approaches have pros and cons.

At Gearset, we favor the iteration approach - we try to slice our product work into small, vertical slices, releasing good now instead of perfect later. In this post, I'll explore why we prefer that approach, what we mean by "small, vertical slices", and how we achieve it in practice.

Instant rollbacks without interruption: how we ship new versions of Gearset every day

Gwilym Kuiper on October 12th 2020

Releasing changes to production is scary. All sorts of things can go wrong. What if that new feature you just implemented contains a bug that you didn't spot in testing? Or maybe that bug you fixed causes an issue in an unrelated area? Maybe there's a performance issue that doesn’t show up until you hit production workloads?

At least you know you have a version of the product that works: the previous version. With an instant rollback, you can switch to the old version immediately, and if you’re lucky your customers won't even notice.

Once you've got instant rollbacks in place, you can release more often and with confidence - knowing that if something goes wrong, there's a safety net in place.

A company built on DevOps: how we release Gearset to our users multiple times per day

Oli Lane on June 26th 2020

We’re proud of our engineering culture here at Gearset. We've built the sort of team we all want to work in: open, collaborative, laser-focused on quality, pragmatic, and unencumbered with unnecessary process.

This great culture brings a whole host of benefits both to us as engineers, and our users. It enables us to iterate quickly, build the right things at the right times, and deliver real, tangible product improvements week in week out - all without ever compromising on uptime and reliability.

To give one example, we make sure that releasing Gearset to our users is as easy and robust as possible, and work hard to continuously improve that process. We release to production 2-3 times per day and we’re still working to boost that cadence. In this blog post, I’ll dig into the reasons we value being able to release so often, and how we achieve it in practice.

Gearset's roadmap for Q1/Q2 2017

Matt Dickens on February 14th 2017

TL;DR: In the first half of this year we’ll be focusing on:

• A small number of substantial new features
• Lots of incremental additions, usability enhancements and polish to existing features
• Making your deployments successful with improvements to our dependency and problem analysis

Gearset exists because migrating changes between Salesforce orgs is difficult. There are often a lot of error-prone manual steps and tedious iteration when making a deployment from one org to another. As your environments grow in number and complexity, so does the margin for error, introducing more esoteric dependencies and failure cases. By the time you add source control into the mix, you're dealing with the idiosyncrasies of the metadata API, versioning issues and lots of raw XML.

No roadworks on this roadmap

Jason Mann on November 24th 2015

When we launched our roadmap in early October, we promised it would be a living document, updated as we deliver new features. Over the past few weeks, we’ve been striking a brisk pace with new feature development - so fast, in fact, that the blog is yet to fully catch up! The result of this is we’re on schedule to deliver all the promised features for this quarter, well ahead of the Christmas shutdown.

Processing the world's Salesforce metadata isn't easy!

Kevin Boyle on November 13th 2015

Gearset works differently to any other deployment or release management solution for Salesforce. Other tools, like the Force.com Migration Tool (ANT), use the Salesforce Metadata API to get the metadata as text files, but have no understanding of the actual metadata within those files.

Gearset processes the files downloaded from the Metadata API to have a semantic understanding of the metadata, including the relationships between objects. This allows us to do things like detect missing dependencies, detect API version mismatches on APEX, deal with differences in history tracking (blog), and deal with quirks in Salesforce deployments that require understanding of your org metadata to work around (blog).

Any deployment service that doesn’t have a rich understanding of the metadata will always encounter these bugs and at best will only ever be thin automation around the Salesforce Metadata APIs.

Customizing Salesforce comparisons: user-driven design in Gearset Deploy

Stephen Chambers on April 21st 2015

When it comes to the design, implementation, and release process, life’s been a whole lot easier working on Gearset Deploy than perhaps any previous project. There’s been no single defining moment, but if you asked me to pick the most significant of the contributing factors, I’d have to go for the involvement of users earlier in the design process.

This has been facilitated – or, as it turns out, supercharged – by using Slack, a team communication platform, to create external channels where users can hang out, talk, and discuss features or challenges. We’ve also added users to our GitHub repository so that everyone can create, view, and comment on specific issues and see progress.

So, how has early user involvement helped with our latest release?