Why Your Organization Cannot Live on Git Alone
Twistlock sponsored this podcast.
Why Your Organization Cannot Live on Git Alone
The creation of the Git open source code repository by the principal developer behind the Linux kernel, Linus Torvalds, certainly qualified as a stroke of genius. But while Junio Hamano continues to do an excellent job of maintaining open source Git, organizations looking to make the jump to so-called agile development and deployment cycles must look beyond relying on a Git’s core version control and software repository capabilities.
Call it growing pains, if you will — but the next stage in DevOps agility requires much, much more. This especially applies to DevOps teams looking to multiply the cadence of deployments with security embedded at the beginning of the cycle (yes, while easier said than done, it is possible).
Getting there requires a rethinking of the traditional software development cycle. This involves doing the necessary so that as soon as the code is stored on Git, the code is instantly integrated into the main production pipeline.
How to make the jump past using Git mainly as a software repository for version control was the main subject of conversation with Ashish Kuthiala, director of product marketing, GitLab, for this edition of The New Stack Makers podcast recorded during the KubeCon + CloudNativeCon conference held in Barcelona at the end of May.
However, Git has and should continue to play its part in the software development and delivery in the indefinite future. Git, indeed, has its place in DevOps. Kuthiala noted how open source Git offers well-known advantages over other repositories, including its distributed mechanism, its speed and the ease and elegance with which it enables code-sharing. But as mentioned above, that is not enough.
“If you look at the complete software development lifecycle when storing code somewhere, then taking it and making it usable for the end user — you still very often have traditional software process that in place that needs to go through traditional software development lifecycles — and that hasn’t changed for a very long time,” Kuthiala said.
This traditional build and deploy model continues to still often involve different specialized teams, each separately adding code to the repository and testing performance and security before the code is processed by operations. “So, there’s still a lot of manual handoff from one team to the other. But this is changing and isn’t really that acceptable anymore in a world that wants to go faster,” Kuthiala said. “The customers want to use software as a differentiating mechanism for their competitors and you need to respond really fast. And this manual hand-off process is error-prone, takes time and ultimately, is costly.”
It was this problem that prompted GitLab to see the importance of how a repository by itself was insufficient to accommodate where software development was headed. The end result was enabling DevOps to merge all the processes into a single application. “As soon as you’ve committed your coding into Git, it will start building and integrating into the main track. And the users found this experience to be immensely valuable, which led to the realization that since there are so many stages in the software development cycle, it is necessary to really not have to stitch together many different tools,” Kuthiala said. “And so, [GitLab] has built a single tool for the entire application development process, especially focused on DevOps.”
The numbers say a lot. Kuthiala said GitLab’s software-as-a-service sees about 165 to 170 deploys a day. For the self-hosted version, Based on the open source forum model, a realize takes place on the 22nd of each month, which has occurred during the past “90 plus months without fail,” Kuthiala said.
GitLab’s external contributors number more than 2,200. “Our customers are all actually contributing code to make this better,” Kuthiala said. “Our customers, they’re all working to better each other.”
In this Edition:
1:22: Adoption of Git and GitLab.
4:48: Process and the silo.
7:32: Metrics.
13:20: Reality check for the present time for development.
15:25: The idea of DevSecOps.
21:24: Cloud native development.
KubeCon + CloudNativeCon is a sponsor of The New Stack.
