Learnings from Github Universe

Originally Published Nov. 2018

TLDR:

• Non-SOX teams should consider adopting Suggested Changes as part of their workflow, speeding up their development cycles.
• Companies should consider looking into the WhiteSource Security PlugIn to increase the efficiency of identifying security vulnerabilities as part of automated checks.

A few weeks ago, I visited San Francisco to attend the Github Universe Conference. Here are some highlights:

New Github Features — Suggested Changes — Github’s new suggested changes feature allows the developer to simply accept a suggested change on the Github interface, rather than copy on the interface, paste locally, make a new commit, etc. Unfortunately, this may slow down SOX teams at WeWork. SOX teams require two prod reviewers who are not contributors to the PR. When the author accepts a suggested change, the reviewer becomes a contributor and is no longer eligible to be a SOX reviewer. This necessitates another developer to review the PR from scratch.

New Github Features — Token Scanning — Say you accidentally deploy a token to production. Even if you un-commit the token, it still lives in version history, necessitating you to call out to the provider for a new one if you don’t want an active token floating around. Github mentioned they would help streamline this process by automatically contacting the provider, seeing if the token worked and requesting a new one if it did.

Measuring Developer Productivity: Circle CI CTO Rob Zuber took an interesting crack at how to measure if an engineering team is high-performing. During the talk, he discussed a ratio around failed builds / total builds. Read more about how they think about metrics here.

WhiteSource Security Plugin: Again, the talk doesn’t seem to be posted, but VP of Product David Habusha talked about his company’s product, which automatically identifies security vulnerabilities as part of the automated checks. WhiteSource doesn’t just tell customers if they are using a library with a vulnerability, but rather highlights the exact lines of codes that might be vulnerable

Airbnb’s Journey into Microservices: an Airbnb “developer happiness” engineer Jens Vanderhaeghe discussed their strategy in disabling their monolith “the MonoRail.” He emphasized they generally waited until they saw things becoming an issue in the metrics and then break apart. They are breaking their monorail into a frontend and a backend component and will be doing a code-freeze on the monorail for new features for one year, which I thought was fascinating. They also managed a mid-phase (before declaring the microservice strategy) of having production engineers manage deploys during the day and having free-deploy in the off hours.