Continuous Integration Cross-Platform Application Building

Continuous Integration Cross-Platform Application Building

Automating the process for less painful deployment

One of the great things about GitKraken is that it is available on all three major computing platforms, and it looks the same on all those platforms. This is a real boon to those devs working across locations, machines and/or operating systems, as they can launch that same familiar UI no matter which system they’re using.

Building Cross-Platform

This cross-platform consistency is all thanks to GitKraken being built on Electron. The underlying Node.js code is mostly platform independent, but what we do with that code to build the app is very different depending on the target operating system.

We need to build the application three different times, on three different platforms, and we need to build it often, frequently, and continuously. We are an agile company, so we position ourselves to always be shipping new code. Be it a new feature, or a nasty bug fix, it needs to go out quickly and with confidence.

Continuous Integration

When we build, the key to success is our continuous integration (CI) pipeline, and the beautiful world of automation.

There are numerous companies that offer automated build systems as a service. We currently utilize the CI SaaS services from both TravisCI and AppVeyor. These solutions allow us to have faster setup times and almost zero hardware or administrative costs. TravisCI builds both our MacOS and Linux builds, while AppVeyor handles the Windows side of things.

SaaS vs On-Premises

Of course, there are advantages and disadvantages to choosing SaaS over an ‘on-premises’ solution. Giving up absolute control of our builds can be a daunting prospect, and customization is a lot harder when we no longer own everything. With a custom setup, we can ensure reliability by architecting something that is as complex (and expensive) as we choose. With services, we need to put our faith in that provider.

There is also the flip side to zero sunken costs: Recurring monthly invoices. Regular costs, spreading out to infinity like a beautiful college loan debt. But, as any good therapist will tell you, compromise is the name of the game, and for our current needs, CI SaaS is the way to go.

Source Control

For CI to work well, we need to keep our code repository as the one source of truth. Source control is an amazing thing.

We keep all build steps in the repo. Every single strange configuration setting that is required for a successful build lives right next to every strange workaround our code needs to complete a task. Version control keeps everyone on the same page and, to get technical for just a second, keeps the crazy away. What happens when Philip the Build Engineer decides he wants to travel around with a circus in the Rust Belt? Nothing. Because all of the tribal knowledge and its history is right there in the repo.

I know what you are thinking: “We don’t store secrets in the repo!” That’s a good mantra. It’s the one exception to keeping everything in the repo. Our secrets are… well… secret. There are two approaches we follow when dealing with the hushed whispers.

Our first approach is to encrypt the secret and store it in the repo. (Remember, we love the repo!) Any kind of file like a signing certificate or access key can be encrypted using another secret and then safely committed. We try really hard to keep everything in version control.

The second approach is to securely transfer the secret to the SaaS platform. Variables are then inserted during build, and our software can utilize them freely to decrypt or authenticate.

Automate All The Things

The CI process can seem daunting and overwhelming at first, but don’t fret, it’s all in the repo! Any team member can hop into the source and look at the various YAML files that define exactly what will happen during the builds. And the joy of automation is that it is… automated. There is no manual interaction that needs to take place. If there is, you’re literally doing the opposite of automation. When the build fails, it’s failing due to a newly introduced code error, not because Francis forgot to set a vaguely defined, yet required, build option.

We don’t even want the pressure of telling the systems to start the build. As you may recall, these are continuous builds. Who has the time to fire them off by hand when GitHub hooks are always listening? When code is committed to our repo, the GitHub hook fires off an event to our provider and a build is triggered. Easy-peasy. Set it, and forget it.

Our mantra is that if it can be automated, it should be automated. If you are doing something manually, you better be sure it is documented inside and out. But even then, we’ve noticed that as soon as documentation is published, it’s pretty much already outdated. If it’s outdated and something breaks, your entire CI process is broken. So, automate!

If you have a manually executed step, someone needs to own it. “Don’t worry,” you say. “Paulette does that step,” you promise. But Paulette is on a cruise in the South of Italy, remember? Automate! Everything needs to be repeated. Everything needs to be repeated. Everything needs to be repeated. Automate!

An automation flowchart for you.

An automation flowchart for you.

We may spend some extra time at the very beginning, making sure the process is solid and automatically reproducible, but that time investment pays off tremendously time and time again once that reliable process is in place.

If it’s not automated, it’s not continuous. If it’s not continuous, it’s not iterative. And if we aren’t iterating, we are stuck in time.

Stay on the cutting edge of software development by getting innovative tips, trends and stories delivered to your inbox every month!

Agile project management software
Plan, develop, review, and ship fast


Legendary suite of developer tools
GitKraken Git GUI, Boards & Timelines