We’ve talked about how the seamless collaboration between Development and IT operations is a beautiful thing. When an organization has a healthy DevOps culture, they’re able to meet business objectives and increase delivery speed. DevOps is meant to eliminate silos so everyone can get on the same page, and the tools you use can play a big role in just how successful, or unsuccessful, your DevOps strategy is.
Complicated tools create silos
One of the ways that operations can be at a disadvantage is by having to maintain a complicated plug-in environment. This scenario becomes especially problematic when things go wrong and developers are relying on a specific group to fix the problem. While specialization isn’t necessarily a bad thing (devs shouldn’t have to do ops, and vice versa), usually the expertise needed to manage a plugin environment is a specialization within an already specialized group.
Jenkins is the most popular example of this kind of complexity, for a few reasons:
-
Jenkins architecture requires maintaining a large set of build environment systems: At scale, this requires many dedicated people to manage machines, install and manage build tools (NodeJS, Python, Java, et al.), monitor machines, etc.
-
Upgrading is a risk (Jenkins or plug-ins): There is a good chance that upgrades can cause processes to fail, leading to broken builds or downtime.
-
Groovy is hard to maintain: This isn't a widely popular script language, so it is harder to find experts to manage it and it's hard to debug due to a lack of debuggers.
-
Jenkins does not support any kind of clustering or failover: The web UI is run on a web container known as Jenkins master, and you can only have one. For a large team of developers needing to use Jenkins all at once, that one instance needs to be very closely monitored with limited permissions.
A large Jenkins plug-in environment creates silos within silos and knowledge gaps that are hard to overcome. What this leads to is a “throw it over the wall” team dynamic: Because the system depends on the expertise of a very limited number of people, developers have to submit code and hope their experts have the skills to manage it.
Lack of visibility keeps teams in the dark
In order for DevOps to thrive there needs to be an understanding of what every team is doing and clarity around processes. Unfortunately, a tool like Jenkins doesn’t necessarily facilitate this. Because users can’t see other users’ commits, they can’t visualize the SDLC as a whole. This only isolates teams even further.
Teams that work within this plug-in environment often download the plug-ins they need, which makes it hard for Jenkins admins to standardize across teams. That, in turn, makes it harder for admins to manage the dependencies and maintain plug-ins properly, which can lead to more broken builds.
While plug-ins are a common way to add functionality into a toolchain, it doesn’t address the problems of a toolchain that hinder teams trying to implement DevOps:
- Lack of visibility
- Knowledge gaps
- Work silos
Why single application CI/CD makes better DevOps
As a complete DevOps platform delivered as a single application, we provide a tool that covers all parts of the SDLC from one interface. CI and CD are just one part of the lifecycle, and by having functionality like SCM, Issue tracking, Security testing, and Monitoring built right in, we’re making it easier for teams to work with DevOps best practices.
If you would like to see a demo of GitLab CI/CD and how we compare to Jenkins, and access other curated content around CI/CD, you can watch our most recent webcast.
