How to Talk About Rails 4 With Your Friends

Spoiler alert! Greenhouse recently deployed Rails 4.

The Rails 4 upgrade to our core recruiting product was a big part of our engineering team’s workload for a few months this summer and fall. In any week, there were 3 or 4 product engineers on the project full-time. And as we approached our deployment date, we drew in an infrastructure engineer, our QA manager and several members of our customer success team. It felt like a group effort and it went well.

The evening right after our deployment, I hung out in the office chatting with some co-workers. My brain was fried and I didn’t feel like coding. And dammit, I was proud and relieved that such a big project had deployed without any major problems.

So I have to ask you something, said one co-worker. It’s a dumb question. But what is Rails? The whole company is talking about it, and I have no idea what it is or why it’s so important.

I replied that it was not a dumb question at all. We work in departments that have little contact. Why should you know my jargon? We spent the next 20 minutes or so just talking about the project and why it demanded so many engineering resources.

Technical expertise doesn’t make you smart. In fact, the first test of your own job knowledge is the ability to explain your work to somebody from another department or industry. It’s one thing for your benefits administrator to understand the terms of the insurance plans your employer offers. It’s their job to know that. But it’s another for them to explain the options in plain language, so you can make the best decision during open enrollment.

As an engineer, I get paid for my ability to upgrade Rails 4 smoothly or to fix bugs or to build features. I earn a salary that could be put to better use if I could not do these things. So the least I can do is explain to the rest of my company what I do and why it’s important. Or to have a plain English answer when my friends and family ask what I’ve been working on.

So here goes — my attempt to justify my existence. That is, to explain the Rails 4 upgrade with minimal jargon. Hint, it was pretty hard to write this.

What is Rails?

Rails is the short name of Ruby on Rails, an open-source, opinionated framework for building a full stack web application like Greenhouse. Think of it as a set of rules and conventions for building a web site in the Ruby programming language.

Customers can’t really see the application that Greenhouse is built on. But it’s critical to our engineers. Rails defines the syntax, rules and tools that we use to build and maintain the product. And it brings its own security features that are important to protecting our users from attacks.

What is a full stack web application?

A web application is a piece of software that you access over the internet; it’s not installed directly on your computer. A full stack application is software that is built around a few core parts:

• an interface that users interact with through a web browser such as Chrome or Firefox;
• a database that stores and organizes the app’s data in a structured way; and
• a server that handles web requests from the browser;

Think about Greenhouse. Users visit the site through a web browser. Once logged in, the user creates or edits data through the app’s interface. For example, when you import a resume into the app, you’re creating a new candidate. You can later go into the candidate’s profile to edit a phone number. When you advance that candidate through an interview stage, the app remembers that stage the next time you visit.

Compare Greenhouse to a marketing site advertising a local doctor. You can’t really interact with it. It tells you the doctor’s hours, address, and biography, and maybe lets you submit a form. But it probably doesn’t let you create a profile, or otherwise edit data on the site.

Why do we need a framework for building web applications?

Our end goal is to build a product that makes customers happy, keeps data secure and is easy for engineers to maintain. The framework is just a tool to that aim. Maybe we could use a different framework, or a language other than Ruby, or no framework at all. The end-user would likely not know the difference. But our engineers would. Although a framework has cons, it does provide rules and conventions for engineers to follow. By using one, we cut down on repetitive, boilerplate code, and are more free to write the business logic of our product.

Imagine your significant other sends you to the market with instructions to buy everything you need for a nice dinner. You know what the end goal is. But you have no idea how to get there, because there are a lot of options and you have no rules or constraints on what to cook. So you wander around the store for a while trying to figure out what to make. It’s tough, because you don’t even know what you’re eating or how to cook it.

Now imagine you’re told to recreate that nice catfish dinner you had during your trip to New Orleans. And are given a Cajun cookbook. So you buy catfish and cornmeal, and head home to make po’ boys and hush puppies.

There are lots of ways you could have shopped that lead to the same place — dinner. But your choice of cuisine — say Italian or Cajun — brings its own constraints and rules. They let you stop thinking about every little decision for your dinner, and to get to the important part (eating po’ boys).

Why did we need to upgrade from Rails 3 to Rails 4?

The most pressing reason is that older versions of software are especially vulnerable to attackers. When the newest Rails (Rails 5) came out in an early form recently, the maintainers of the Rails project dropped security support for Rails 3. That means there would be no guarantee that they would fix any security flaws in Rails 3 as they were discovered. We would be left to write our own fixes or depend on developers not affiliated with the Rails project. Rails 4 is current, and is completely maintained.

Rails 4 also brings new features that developers appreciate. Moreover, there is a large ecosystem of third-party libraries that add functionality to the core Rails app. In time, these libraries also drop support for older versions of Rails.

Rails 4 is an open-source project. How is this different from proprietary software?

Rails is an open-source software project; its code is completely public and free to use. Greenhouse does not require a license to build our product on Rails. And any developer can propose a change to Rails. Compare this experience to using Adobe Photoshop — you pay for it. Or if I wanted to develop a change to iOS, I’d be out of luck. iOS is completely closed, proprietary software.

Getting changes into open-source software is democratic in theory, but there are certainly controls by which other developers review your work and decide whether the change is warranted. Also, even an approved change may not be released right away. Small changes are put into a minor release, and big changes into a major release. Rails 4 is a major release.

Why were we so concerned about this release?

Although we’re constantly releasing new features and fixing bugs, sometimes we release an extremely big change that has the potential to break things badly. We have many ways of testing code before it is live to our customers. But we can’t always anticipate all use cases. Maybe the app will perform differently for large companies with 10,000 candidates, or for users that have not logged out in months, or…there are many potential edge cases.

So the Rails 4 release had us particularly on edge and demanded a special strategy.

What is is this special strategy?

Our Rails 4 release was one of Greenhouse’s first so-called blue-green releases. This means that we start by only exposing a small subset of customers to the new code. We’ll wait maybe an hour, and use monitoring tools to ensure that we have not introduced new bugs. If we do see new bugs, we may revert these customers to the old code while we fix the problem. This step is known as a rollback. If things look good, we’ll expose additional customers to the new code.

In this case, we started by routing only internal customers to Rails 4, and then only 5 percent of external customers. We then moved up to 10 percent, and then 20. But when we found a bug, we rolled back all customers to Rails 3. After we fixed it, we moved 30 percent of customers to Rails 4, and so on until 50 percent were exposed to the new code.

Then…we waited. Overnight. This was to allow background jobs to run, whose effects would not be visible for up to 24 hours. The next day, we decided were satisfied and moved all Greenhouse web requests to the version of our product running Rails 4.

What are background jobs?

Background jobs are tasks that may take a long time to run or consume a lot of system resources. At its core, our app has a web server that listens to user requests to visit a page or to edit a single candidate’s profile. But imagine if an admin user at a large customer wanted to bulk edit the profiles of 10,000 candidates. Would you want to interrupt your normal work in the app until all edits went through? What if some edits fail? It makes more sense to handle the edits in a separate process from the user’s main navigation of the app. This way the user is not blocked from using Greenhouse while resource-demanding tasks are running.

Summing up

So there you have it. Moving from Rails 3 to Rails 4 took months of work and had the potential to cause bugs in our app. This is because Rails 4 is a major change to the technical rules and conventions on which our app is built. We tested the release of Rails 4 extensively through our automated test suite and the hard work of our manual QA engineers. But no amount of testing can truly predict the far-reaching effects of such a change. So we used an incremental release over two days that allowed us to monitor the effects of Rails 4 on subsets of customers, and to quickly reverse changes in order to fix bugs.

I worked intimately on this project for a few months. Being able to talk about it with minimal jargon is hard. But it’s a worthwhile skill that makes an engineer better able to justify a large technical project and to communicate about it with the rest of the company. In fact, the project really picked up steam when the team leader began to send regular updates that showed our progress and the remaining blockers.

See you on Rails 5?

. .

Adam Barcan is a Software Engineer on the Product Engineering team.

Want to work with Adam? We’re hiring!