Posts from August 2015

Continuous Integration (CI) and Delivery (CD) are a core processes within our engineering team. CD is hard to get right, and we pride ourselves on following best practices. In the cultural sense, we imbue the central values and DevOps culture in general: continuous improvement, tight feedback loops, automation, education, blamelessness, and autonomy.

In fact, it can be argued that CI is an absolute baseline requirement in modern software development. It is the hub for all spokes that make up engineering (devs, ops, QA, management). The build and release pipelines are therefore a mission critical production distributed system, and should be treated as such. But what happens when the pipeline (or parts of it) goes down? Important fixes can’t be pushed out, developers get blocked, visibility is lost, and everyone notices. Worse, when the problem is resolved, the commits have piled up and an important tenet is broken: small incremental changes vs. large deployments.

When starting out as a monolithic app developed with a small team, you can easily get away with just configuration management and a simple build server (eg. Ansible & Jenkins). But as time moves on, the product, team and company grow, and that monolith is half way transitioned to a handful micro-services.

Last ½ year we took a step back to look at things with a bit of perspective. We can’t just hire someone to monkey around with Jenkins and expect our growth problems to go away. A deeper re-examination and contemplation of the current issues (and future requirements) needs to take place. With a solid design philosophy, implementation more easily falls into place and decisions are made within the proper context. So, in the spirit of openness, we’re opening up our dev process in the hopes that we get insights from unexpected places and that we unexpectedly help others by providing lessons learned.

Read More …

So you’ve written this great new feature and you can’t wait for your customers to see it. The tests are passing and it looks good on your laptop. Now you just have to get it out in the open – but how do you do that?

The answer is the deploy system – the process of making the technology we create available to our customers, in the shortest time possible, checking that no bugs are caused in the process. There are many possible ways to build and deploy software, each with their own merits. Focusing time and attention on an effective build system means delivering functionality customers as opposed to losing time with processes that could otherwise be automated.

Over the past few months, we’ve been working on a new deploy system for Hootsuite Analytics. We can’t stress enough how important this process is – without it, we’d have great products that nobody would ever see. Having millions of customers, we want to be able to quickly and safely release new changes to all of them – this requires a deployment system that is consistent, fast and finds as many issues as possible before shipping out changes. This post describes our move to a Blue-Green deployment system for our Hootsuite Analytics product.

What exactly are we deploying?

In order to understand our needs, let’s go a bit through what we need to deploy. There are two main components – the web servers (we also call them web nodes) and the data processing pipeline. This post is all about the web nodes, so let’s focus on those. They are what customers directly interact with, so besides having to be up all the time, we cannot have any interrupted requests. This makes deployment a bit tricky, because we need to be sure that a server is not shut down while replying to a request.

Read More …

You’ve heard the stories – mid-day Nerf battles, golf carts in the office, plaid shirts as far as the eye can see – but have you ever wondered what it’s REALLY like inside Hootsuite? Do we all have dogs and matching beards? Does craft beer run through our veins? How well do we code during yoga time?

Get answers to these questions and many more on August 12th during the #hootjobs Twitter chat!

What is #hootjobs? 

At Hootsuite, we do a lot of hiring. A few months ago, we launched #hootjobs on Twitter as an easy, interactive way for people to engage with our recruiting team. Prospects, job seekers, and the curious are invited to ask questions about job openings and life at Hootsuite, with our Talent team on hand to answer. This week is our first Departmental Spotlight and your chance to meet some of our Engineering team as they showcase their work, the people, the culture, and more.

Let’s Talk Engineering @ Hootsuite

On August 12th, Beier Cai and Geordie Henderson will be online to personally answer your questions about life in Engineering at Hootsuite. Beier is our Director of Technology (and was Hootsuite employee number 3), while Geordie is the VP of Engineering. What’s the difference? What are they looking for when they interview potential engineers? What do new hires work on when they start? Find out what you want to know.

All hands on deck for the Hootsuite Instagram launch!

How Do I Participate?

The special Engineering edition of #hootjobs takes place on Wednesday, August 12th, between 12 noon and 1pm PDT on Twitter. Be sure to follow @hootsuitelife and @hootsuiteeng, and use the hashtags #hootjobs and #hootsuitelife to follow along. You can expect a lively discussion about Engineering at Hootsuite, the positions we’re recruiting for, and a few secrets along the way. Hope to see you there!



  1. As JasonR1 points out in the comments, the bug/feature referred to in the “Working with Older Xcode Versions” section has made a comeback in Xcode 7.1, so please review the information below as it’s once again relevant.

  2. As featherless points out in the comments, distributing frameworks written in Swift via a pre-built .framework file (as opposed to via source code from which users can build the framework themselves) can be problematic. In order for your app to build properly, it and the frameworks it uses must have been built with the same version of the Swift compiler. Since Swift is changing so quickly, maintaining compatibility of the framework with whichever version of Xcode a consumer of your framework is using quickly becomes a hassle. For this reason, you may want to use Objective-C or distribute the source code instead.
With iOS 8, Apple introduced a number of app extensions such as the Share and Today extensions, as well as WatchKit extensions for interacting with WatchKit apps. To facilitate building these extensions, Apple introduced a new (to iOS) type of framework called an embedded framework. The typical use cases Apple has shown for using these frameworks revolve around projects where the embedded framework’s code is included in the same project as the code that uses the framework (e.g., an app with a Share extension packaged up as an embedded framework residing in the same project). What hasn’t been quite as clear is how one can distribute these frameworks when the framework’s parent project and the framework consumer’s parent project are not the same project.

At Hootsuite, as we create new apps beyond our flagship iOS app (such as Suggestions by Hootsuite), we’ve become interested in sharing code between our apps as well as between our individual apps’ main target and their various extensions. For example, many projects (including the main Hootsuite iOS app) define their own branded fonts and colors in a category on UIFont and UIColor. Replicating this across several apps, each of which has several of its own extensions, quickly leads to duplication of this code many times over. The same can be said for common networking code, custom UI elements, etc. These new embedded frameworks appear to be a great way to share such common code across projects. Read More …