Combine continuous integration software with GIT
As microservices abound, organizations are finding that integrating Jenkins CI with source code tools like GIT can simplify development and help make the DevOps successful.
Given the new reality that microservices, CI, DevOps and reactive programming have thrust upon the software community, it's no surprise to discover that vendors specializing in the fundamental task of managing source code are working hard to integrate continuous integration software like Jenkins and Hudson into those tools from the start.
The ongoing love affair the enterprise Java community is having with reactive designs, promoting DevOps and packaging with continuous integration software is not only affecting the way software is designed and developed, but it's also changing the way enterprise software is stored, coupled and deployed. The proliferation of microservices means managing a larger number of projects, each of which will often be stored separately and within separate source code repositories.
We see that there is a microservices revolution happening, so people are splitting up more and more applications.
Sytse 'Sid' Sijbrandijm,
co-founder and CEO, GitLab
The trend toward continuous integration means some type of coordination between these loosely coupled and separately stored systems is required. The trend toward DevOps means developers want to play a role in how applications finally get deployed.
"We see that there is a microservices revolution happening, so people are splitting up more and more applications," said Sytse 'Sid' Sijbrandijm, co-founder and CEO of GitLab. "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." So, what's the solution to the challenge of managing all of these new GIT projects? According to Sijbrandijm, integrating a CI tool like Jenkins into the source code management tool is the answer, which is exactly what they've done in the latest version of their software. "CI is something you should do in every project, and if you have a lot of projects, it's easier if it's part of the tool itself."
Storing Jenkins configurations in GIT
The benefit is not limited to the management of source code and ease of deployment. There are development benefits as well.
Historically, managing a Jenkins repository was more of an operations role. But it's not unreasonable to think that a developer might need to make some Jenkins configuration changes to integrate a new microservice, or integrate a new asynchronous messaging stream. In the new world of DevOps, we want to trust developers with operations tasks, and operations people to be trusted with development, so it only makes sense to allow a developer to make minor changes to the Jenkins server. Of course, all changes need to be checked in, tested in a new development stream, and only integrated into the master stream only after the testing harness signals an all clear. But that just emphasizes why Jenkins should be maintained within GIT and not managed externally. "If you make a new function in your program -- maybe you need to change something in your CI," said Sijbrandijm, "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."
By downloading and working with GitLab's omnibus package, you get this integrated Jenkins functionality, along with a variety of other tools to help manage and maintain software quality. To hear more about how GitLab is encouraging a DevOps-based approach to system development, while responding to the proliferation of modern architectures that depend heavily on microservices, asynchronous messaging and loosely coupled systems, listen to the associated podcast between Cameron McKenzie and Sijbrandij.
Do you think integrating Jenkins into your GIT repository would help your organization implement DevOps? Let us know.
