How Plaid uses GitHub

Plaid's Developer Efficiency team speeds up workflows with developer happiness—and GitHub—at the heart of their operation.

Location: San Francisco, CA
Industry: Financial Services
Number of Seats: 430

About Plaid

Plaid's API provides a simpler way to confirm account ownership in just a few clicks, making it a linchpin of popular payment apps, brokerages, and more. What started as a single API for accessing consumer-permissioned account and routing information has expanded to include more data types and intelligent logic, like machine learning and fraud detection models.

Behind Plaid's technology is a staff of more than 500—including over 200 developers—with engineering offices in San Francisco, New York, Salt Lake City, Amsterdam, and remote locations. The Developer Efficiency team, led by Engineering Manager Jeeyoung Kim, is responsible for helping developers work smoothly and connecting them to efficient, dependable internal tools. Kim describes his team's role as rooted in developer happiness: "We want to make sure Plaid engineers are happy and that their tools aren't getting in their way."

GitHub as the Foundation

Plaid has used GitHub since its launch in 2013, and it remains the foundation of their development lifecycle. "GitHub has been vital to Plaid engineering ever since day one," Kim says. The company's first repositories were hosted on GitHub.com, but their unique security needs required them to run much of their software on a VPN. "We self-host as many tools as we can," he explains. They've since migrated their code to a self-hosted instance of GitHub Enterprise to manage their own infrastructure while taking advantage of core flows, like pull requests.

"The UI is polished, and everyone is accustomed to it," Kim explains. "So when we want to add additional functionality to the development workflow, it's much better to build on top of GitHub's interface rather than rolling out our own version."

Pull Requests as a Development Language

Kim sees pull requests as much more than a vehicle for change. They allow developers to structure their thoughts and add narrative and context to a new feature or bug fix. "A pull request is a solution," says Kim. "It allows developers to gain more comprehensive context. And makes them less likely to accidentally introduce bugs in unrelated systems."

Pull requests are increasingly the language that Plaid engineers use throughout their work. Using GitHub as a base, Plaid developers build engineering workflows with software that accelerates and automates every step of their development cycle—from pairing the platform with Jenkins to experimenting with GitHub Actions.

Automating Infrastructure Changes

To make and manage production changes, Plaid uses Atlantis, an application for automating Terraform via pull requests. If developers want to create an additional database, new services, or a new set of load balancers, these changes are propagated through Atlantis to Terraform.

Atlantis is integrated as a GitHub Webhook server. "You just leave comments on your pull request," says Kim. The comment "Atlantis plans" previews the changes it plans to make. And if you're happy with the plan it generates, "Atlantis apply" makes the changes on production.

Custom Workflows and Integrations

Kim's team has built on GitHub's code owners feature with custom logic that streamlines their review process. They built a GitHub webhook receiver for tagging people who should be notified about a given pull request, allowing them to loop in reviewers without blocking the process. Because the team has their own GitHub webhook receiver, they can automatically notify Slack users when a pull request that's eligible to be merged passes or fails.

Integrating with Slack helps developers stay in the flow and keeps team members who aren't on GitHub in touch with product developments. "Bringing GitHub updates into Slack gives developers another option and increases the responsiveness and the usability of our system," notes Kim. "By keeping developers tuned in, it helps everyone work faster."

Accelerating Deployments with Canary Releases

The team leverages canary releases to make deployments more efficient. Whenever they deploy, they deploy a pre-merged commit to a Canary environment and allow very small amounts of traffic to flow against that environment before the pull request is fully merged. "Without having to go through a different environment, developers don't need to wait for the entire CI/CD pipeline to kick in," explains Kim. "You can see the change immediately, right from your pull request. This maximizes iteration speeds by reducing a workflow from hours to minutes. If developers want to make changes to code multiple times a day, they can complete a full day's work within an hour."

Open Source and Innersource

Plaid contributes to the open source community with upstream bug fixes and by releasing open source software. "We stand on the shoulders of giants," says Kim. He sees additional benefits in releasing open source software: "First, it's a branding exercise: you can increase the awareness of the company through open source projects. And second: open sourcing work creates higher quality, more secure, better structured code. It forces you to separate out specialized business logic from the general purpose logic you plan to open source."

The Developer Efficiency team advocates for open source principles applied to internal development through innersource. Nearly all of Plaid's repositories—with the exception of sensitive repositories maintained by the security team—are open to every developer in the company. Kim sees the shared tools and knowledge that accompany more open development as key to keeping developers efficient.

"For a long time, shared libraries were maintained by different teams," he says. "They were created to solve a particular problem, not to spread knowledge." This was causing governance issues in the long term. Teams that weren't impacted by bugs and other issues weren't incentivized to fix them. It's now the team's goal to inherit ownership of these shared components and keep them up to date, dependable, and ready for all developers to use.

Documentation and Knowledge Management

Internal documentation is a top priority for the Developer Efficiency team. "Documentation is something we're always revisiting and improving," says Kim. Most recently, they are working towards unifying documentation from across Confluence, GitHub repositories, and Google Docs into a GitHub Pages site.

"We're happy with the result, so far," says Kim. "Publishing documentation with Jekyll to GitHub Pages uses a workflow that's natural to developers and keeps documentation and code in the same repository. You can make a change to the code and modify its documentation at the same time."

From knowledge management to innovative new toolchains, Plaid's Developer Efficiency team is approaching faster workflows from as many angles as they can. They've proven that small improvements can ripple outward to the larger organization, a reminder that thoughtful tools are force multipliers for the entire company. As Kim puts it: "The more developers can accomplish, the more everyone can."