Tag Archives: pain

Git, clients, partners, and woes.

This post comes from the “hindsight is twenty-twenty department.” A
few years ago when we started our
White Label program, we were
wondering how to manage the different client branding, GUI
customization, etc. Our first thought was “I know! We’ll use
git!”

Then we had two problems.

We used to use one branch in git per white label partner. The
intention was that we would then effortlessly merge across updates and
ship updates and have everything happy. Reality, however, quickly set
in. Every partner branch needed to be kept track of and manually
merged with HEAD. Being a distributed company, keeping git branch
discipline is bad enough when there’s one production branch, and much
worse when someone may commit last-minute bug fixes under the gun on a
completely different production branch. Once that happens, you need to
round up the branches and start merging back, up, down, and heaven
help you if you wind up with a mutually exclusive merge
conflict. Things wound up in a state where our white label clients
would lag months and months behind our production SpiderOak client at
best.

Our first attempt consolidated our generic white labels down to two
branches based on core GUI features included. This did a great job of
reducing complexity, but it still left many very interestingly
customized clients still in their own branches, and it left us needing
to make sure every branch was still lovingly merged and that fixes
accidentally committed to the wrong branch got brought everywhere
else. Something else was needed.

Our first step was to overhaul the builder, which we completed
recently. This gives us a flexible resource framework to drop in
everything from images to configuration files. The next step is to
boil down all our custom white label code into client code and builder
configuration files, which will again bring us back to one
production branch for everything we ship.

What does this mean for you, fair customer? The primary win is that
now, especially as we maintain
multiple
brands just under SpiderOak alone
these days, we will be able to work on features much more quickly and
deploy them to everyone. Bugs found by partners don’t get fixed only
for partners that report them, but for everyone. And finally, we get
only one, single place that we have to aim CI and testing tools. This
results in a far better SpiderOak experience.

And it sure results in a huge reduction in the amount of grey hairs
we accumulate with every release cycle. Our takeaway here at SpiderOak
is to really examine every new process we try to introduce for trying
to imagine even just a single year down the road. On the surface,
using git to manage different production releases of SpiderOak seemed
to be a splendid idea. After a couple of years? Worst. Idea. Ever.