{"id":69220,"date":"2022-12-20T09:00:33","date_gmt":"2022-12-20T17:00:33","guid":{"rendered":"https:\/\/github.blog\/?p=69220"},"modified":"2023-05-15T13:50:52","modified_gmt":"2023-05-15T20:50:52","slug":"how-we-use-github-to-be-more-productive-collaborative-and-secure","status":"publish","type":"post","link":"https:\/\/github.blog\/engineering\/engineering-principles\/how-we-use-github-to-be-more-productive-collaborative-and-secure\/","title":{"rendered":"How we use GitHub to be more productive, collaborative, and secure"},"content":{"rendered":"

It\u2019s that time of year where we\u2019re all looking back at what we\u2019ve accomplished and thinking ahead to goals and plans for the calendar year to come. As part of GitHub Universe<\/a>, I shared some numbers that provided a window into the work our engineering and security teams drive each day on behalf of our community, customers, and Hubbers. As someone who loves data, it\u2019s not just fun to see how we operate GitHub at scale, but it\u2019s also rewarding to see how this work contributes to our vision to be the home for all developers\u2013which includes our own engineering and security teams.<\/p>\n

Over the course of the past year1<\/a><\/sup>, GitHub staff made millions of commits across all of our internal repositories. That\u2019s a ton of branches, pull requests, Issues, and more. We processed billions of API requests daily. And we ran tens of thousands of production deployments across the internal apps that power GitHub\u2019s services. If you do the math, that\u2019s hundreds of deploys per day<\/em>.<\/p>\n

GitHub is big. But the reality is, no matter your size, your scale, or your stage, we\u2019re all dealing with the same questions. Those questions boil down to how to optimize for productivity<\/strong>, collaboration<\/strong>, and, of course, security<\/strong>.<\/p>\n

\"\"<\/p>\n

It\u2019s a running joke internally that you have to type \u201cGitHub\u201d three times to get to the monolith. So, let\u2019s take a look at how we at GitHub (1) use GitHub (2) to build the GitHub (3) you rely on.<\/p>\n

Productivity<\/span><\/a><\/h2>\n

GitHub\u2019s cloud-powered experiences, namely Codespaces and GitHub Copilot, have been two of the biggest game changers for us in the past few years.<\/p>\n

\"\"<\/p>\n

Codespaces<\/span><\/a><\/h3>\n

It\u2019s no secret that local development hasn\u2019t evolved much in the past decade. The github\/github repository, where much of what you experience on GitHub.com lives, is fairly large and took several minutes to clone even on a good network connection. Combine this with setting up dependencies and getting your environment the way you like it, spinning up a local environment used to take 45 minutes to go from checkout to a built local developer environment.<\/p>\n

But now, with Codespaces, a few clicks and less than 60 seconds later, you\u2019re in a working development environment that\u2019s running on faster hardware than the MacBook I use daily.<\/p>\n

Heating my home office in the chilly Midwest with my laptop doing a local build was nice, but it\u2019s a thing of the past. Moving to Codespaces last year<\/a> has truly impacted our day-to-day developer experience, and we\u2019re not looking back.<\/p>\n

GitHub Copilot<\/span><\/a><\/h3>\n

We\u2019ve been using GitHub Copilot for more than a year internally, and it still feels like magic to me every day. We recently published a study<\/a> that looked at GitHub Copilot performance across two groups of developers\u2013one that used GitHub Copilot and one that didn\u2019t. To no one\u2019s surprise, the group that used GitHub Copilot was able to complete the same task 55% faster than the group that didn\u2019t have GitHub Copilot.<\/p>\n

Getting the job done faster is great, but the data also provided incredible insight into developer satisfaction. Almost three-quarters of the developers surveyed said that GitHub Copilot helped them stay in the flow and spend more time focusing on the fun parts of their jobs. When was the last time you adopted an experience that made you love your job more? It\u2019s an incredible example of putting developers first that has completely changed how we build here at GitHub.<\/p>\n

Collaboration<\/span><\/a><\/h2>\n

At GitHub, we\u2019re remote-first and we have highly distributed teams, so we prioritize discoverability and how we keep teams up-to-date across our work. That’s where tools like Issues and projects come into play. They allow us to plan, track, and collaborate in a centralized place that\u2019s right next to the code we\u2019re working on.<\/p>\n

\"\"<\/p>\n

Incorporating projects across our security team<\/a> has made it easier for us to not only track our work, but also to help people understand how their work fits into the company\u2019s broader mission and supports our customers.<\/p>\n

Projects gives us a big picture view of our work, but what about the more tactical discovery of a file, function, or new feature another team is building? When you\u2019re working on a massive 15-year-old codebase (looking at you, GitHub), sometimes you need to find code that was written well before you even joined the company, and that can feel like trying to find a needle in a haystack.<\/p>\n

So, we\u2019ve adopted the new code search and code view<\/a>, which has helped our developers quickly find what they need without losing velocity. This improved discoverability, along with the enhanced organization offered by Issues and projects, has had huge implications for our teams in terms of how we\u2019ve been able to collaborate across groups.<\/p>\n

Shifting security left<\/span><\/a><\/h2>\n

\"\"<\/p>\n

Like we saw when we looked at local development environments, the security industry still struggles with the same issues that have plagued us for more than a decade. Exposed credentials, as an example, are still the root cause for more than half of all data breaches today2<\/a><\/sup>. Phishing is still the best, and cheapest, way for an adversary to get into organizations and wreak havoc. And we\u2019re still pleading with organizations to implement multi-factor authentication to keep the most basic techniques from bad actors at bay.<\/p>\n

It\u2019s time to build security into everything we do across the developer lifecycle.<\/p>\n

The software supply chain starts with the developer. Normalizing the use of strong authentication is one of the most important ways that we at GitHub, the home of open source, can help defend the entire ecosystem against supply chain attacks. We enforce multi-factor authentication with security keys for our internal developers, and we\u2019re requiring that every developer who contributes software on GitHub.com enable 2FA<\/a> by the end of next year. The closer we can bring our security and engineering teams together, the better the outcomes and security experiences we can create together.<\/p>\n

Another way we do that is by scaling the knowledge of our security teams with tools like CodeQL<\/a> to create checks that are deployed for all our developers, protecting all our users. And because the CodeQL queries are open source, the vulnerability patterns shared by security teams at GitHub or by our customers end up as CodeQL queries that are then available for everyone. This acts like a global force multiplier for security knowledge in the developer and security communities.<\/p>\n

Security shouldn\u2019t be gatekeeping your teams from shipping. It should be the process that enables them to ship quickly\u2013remember our hundreds of production deployments per day?\u2013and with confidence.<\/p>\n

Big, small, or in-between<\/span><\/a><\/h2>\n

As you see, GitHub has the same priorities as any other development team out there.<\/p>\n

It doesn’t matter if you\u2019re processing billions of API requests a day, like we are, or if you\u2019re just starting on that next idea that will be launched into the world.<\/p>\n

These are just a few ways over the course of the last year that we\u2019ve used GitHub to build our own platform securely and improve our own developer experiences, not only to be more productive, collaborative, and secure<\/a>, but to be creative, to be happier, and to build the best work of our lives.<\/p>\n

To learn more about how we use GitHub to build GitHub, and to see demos of the features highlighted here, take a look at this talk from GitHub Universe 2022.<\/p>\n

\n