I'm pretty sure that when Linus Torvalds laid down the architecture plans for the Git version control system, the last thing on his mind was developing a SCM tool that would help to drive the DevOps revolution forward, but quite serendipitously, it has.
Friendly forking and cordial cloning
The ability to easily fork or clone a repository, create an isolated branch on which one can goof around without any fear of one's sandbox play making it back into the production code has empowered a wave of operations personnel who want to satisfy their curiosity about how a given piece of software works, or answer the question about "what if I got them to tweak this code into something just a little different, how might that improve things?"
Pushing the envelope in terms of bonding Ops with Git, the venerable GitLab has taken things one step further. In the world of continuous integration and continuous deployment, the standard CI route is to pull code from Git, run the required suite of tests, package everything up, and if all goes well, push into production. Gitlab has decided to take the process full circle and close the loop upon itself by actually having the entire CI configuration itself hosted within Git as well.
Operations and development play in the GitLab sandbox
It's actually a pretty smart play. The idea isn't to simply store the configuration files and leave it at that. The idea is that software developers who are unhappy with the current CI configuration, or who need to make a tweak or change to the configuration can, just like the Ops people did with Git and source code, fork the Git repository storing the CI data, branch it, play around with it, and adjust their CI routines accordingly. If the changes they apply to their local branch improves the quality of the CI routine, a pull request can be made to the blessed master branch, and Ops people can merge in those changes.
"If you make a new function in your program -- maybe you need to change something in your CI," Sytse 'Sid' Sijbrandijm, co-founder and CEO, GitLab, "you should be able to specify that inside the repo, have it registered on the version control, and have your feature branch tested differently from the master branch."
Microservices changing the way source code is managed
Of course, moving CI configuration into Git itself isn't just about DevOps. The fact is, as more and more organizations build larger systems out of discreet microservices, the number of small, individual projects and repositories that an organization needs to keep track of is growing. "Using GIT in the proper way leads to a big growth in the number of distinct repositories you have and it becomes more of a burden to integrate all of the tools," said Sid. Keeping track of all of the CI configuration in Git just makes life easier.
Podcast and article
To hear the full interview between TheServerSide and Sid, the CEO of GitLab, take a listen to the following podcast:
There's also a full write-up of the conversation available on TSS as well:
You can follow GitLab on Twitter: @gitlab
You can follow me on Twitter as well: @potemcam