DevOps and Version Control: Why Microsoft Had to Get GitHub

Unless you've been living under a rock for the past week or so, you've heard that Microsoft is buying GitHub for a reported $7.5 billion in stock. The web has been buzzing since the official announcement came out on June 4th, and the opinions about the acquisition seem about as polarized as they were in response to the 2016 US elections.

The acquisition actually fits quite seamlessly into Microsoft's "developer-first" approach, adopted by the company most notably since CEO Satya Nadella got on board in 2014. Microsoft proudly admits that it relies on open source tools, and has even developed some of its projects (such as the Visual Studio Code text editor) on GitHub itself.

Microsoft is such a heavy GitHub user, in fact, that Microsoft developer and open source guru Miguel de Icaza joked on Twitter: "Satya looked at Microsoft's bill from all the code we host on GitHub and figured it would be cheaper to buy the company."

By embracing rather than fighting the open source movement of the last decade, Microsoft is joining the ranks of Facebook, Yahoo!, Dell and others, who have admitted to choosing open source software for some of their most critical development environments. Open source is no longer the exception; it's the norm.

DevOps and Version Control: Like PB and J?

Version control wasn't anything new in 2005 when Linux creator Linus Torvalds released the first version of Git, but the existing options were missing something key, the ability to track work locally and participate in a workgroup — distributed version control. Centralized systems didn't offer the speed, workflow, or open (read: free) availability that he sought after. GitHub, born a few years later, has become a massive Git-repository hosting service, with an estimated 85 million repositories and 28 million users. Github took the concept of participating in a code project into the social sharing realm.

Over the last decade, Git and GitHub have established themselves as the go-to choice for startups and enterprises alike, offering the incomparable performance Linus Torvalds had once set off to achieve. As DevOps adoption has accelerated in recent years, GitHub has taken an active role in automation, with dozens of reference points throughout the automation and build sequences, version control has long since been adopted as the gospel for code development.

Jenkins rose to fame around the same time, eventually becoming the world's favorite open source build automation tool, with an estimated 70% of the market share as of 2018. Jenkins hosts its own repository on GitHub as well, offering hundreds of plugins to support a harmonious Jenkins/GitHub relationship. This isn't mere coincidence. The fact is that DevOps and version control go hand-and-hand. To really be able to pull DevOps off, you need to have smart, automate-able, and resilience-enhancing controls in place. And that's precisely what's offered by GitHub and other Agile version control tools.

The combination of version control and code repositories for development and an automation server that can easily access the code and build, creates an unparalleled force that drives agility and enables safe teamwork.

DevOps and version control work together through the deployment process to support continuous delivery. Automation code and configuration stored in git gives control and location flexibility so that many nodes can participate in the process. Jenkins integration ensures that it's a fresh git checkout every time the pipeline executes.

Is All Code Equal?

Many organizations benefit from the combined offering for developing and deploying source code, and Microsoft may even be one of them. As organizations have become comfortable with hosting repositories remotely and relying on open source software, this development method is widely used.

However, not all code is treated equally. DevOps, Agile, and open source adoption may have become the norm for application development, but database code is often left out of the equation.

"Why?" you might ask. The reasoning isn't obvious; why is database code different than all other code? It is developed, tested and deployed, just as other code is, yet it is often excluded from the automation and version control story. Perhaps the reason is that the database is perceived as heavy, dangerous to tinker with, old. In reality, however, leaving the database behind creates a bottleneck that slows development and can potentially lead to serious issues.

In reality, there is no real reason to treat database source code any differently. Whether working on-prem or with cloud-based databases (or a combination of both), organizations can benefit from the GitHub/Jenkins relationship; a smooth, Agile development-to-deployment process can be easily achieved for the database, too.

DevOps and version control solutions are instrumental to successful builds and deployments that keep up with the pace of business today. Of course, even with such solutions in place, you're not exactly going to have a set-it-and-forget-it software ecosystem. To push the wheels of progress to that end, you'll need a tool that ties them both together and adds security, governance, and process makes it darn near perfect.

Combine all that with a built-in set of APIs and connectors to other tools in the DevOps ecosystem, and you've got yourself a winner.