GitLab is a complete platform for the entire DevOps lifecycle, but some users and organizations already have a specific tool they must use for certain parts of their workflow. Over 4.5 million projects have configured integrations and hundreds of thousands more are added each month. User utilize integration management to connect a wide array of applications such as Slack, Jira, Prometheus, and more – plugging critical parts of their chosen stack into GitLab.
One of the core design concepts of GitLab as a product is that a single application serves our users best. However, for users who have made specific choices about certain tools in their workflow, the inverse is also true: a disjointed toolchain where your tools are not connected at all is the worst possible experience. If you are going to have separate tools in your DevOps toolchain (which is fine!), they need to at least be sitting next to each other.
Before GitLab 13.3, project integrations were managed only at the project level. This meant that if you had 400 projects, you'd have to configure that integration 400 times!
In GitLab 13.3, we added the ability to add an integration across an entire GitLab instance, for all projects. In GitLab 13.6 (coming Nov. 22, 2020), we’re expanding this ability to work at the group level as well.
Integration management for large organizations integrating third-party applications with their GitLab projects!
A group with any number of projects in it can integrate them all at once, from a single place. Group owners and instance administrators rejoice! This will save you hours and hours of work managing all of those connections and keeping them up to date.
There are also security benefits to this approach: instance administrators and group owners can roll out an integration without having to share the credentials with each project owner directly. This is a great security enhancement because many organizations had to restrict configuration to a small group of people, requiring them to do a ton of busywork just to maintain this posture.
Group-level Integration Management is available today, for free, on both GitLab.com and in self-managed GitLab installations running 13.6 and up.
For more information, check out the documentation for Project Integration Management.
So what’s next for Project Integration Management?
We’re also looking to expand this feature with more bells and whistles to make the lives of our instance administrators and group owners easier. Some things that we're considering for the future are:
- Inheritance overviews, which will show what projects are overriding the inherited settings
- Per-field inheritance that overrides only a single field while leaving the rest of the settings managed by the parent
- Field masking, which allows the group or instance owner to obfuscate specific fields that are inheritable, while still allowing the integration to work
- Inheritance locking, giving group or instance owners the ability to enforce those settings on every project under them
- Service Template migrations, giving users of Service Templates an easy way to migrate to this new feature and roll the change out to every project where it’s applicable
If you have any feedback, ideas for future features, input, or requirements for items on the roadmap, or anything else – please leave comments in the parent epic for this feature.
Upcoming Service Template deprecation
Formerly, Service Templates filled this particular need in GitLab, with many limitations. These templates were applied only to new projects, and if you updated a value on the template, it didn’t retroactively apply to each project that already used those settings.
This solves half the problem by allowing the initial settings of an integration to be defined for many projects in one place, but failed to help with actually managing those integrations later. Because the ongoing management is just as important as the setup, we saw some organizations writing custom scripts to continuously validate that those settings hadn’t changed, and automations to roll out changes to many projects at once. These examples are glue code that they should never have needed to write in the first place, let alone make them maintain over time. Our hope is that this new feature suits those use cases perfectly, and that migrating from Service Templates to integrations managed at the group level dramatically reduces their maintenance overhead.
We are currently planning on deprecating Service Templates during our normal deprecation cycle (only in major releases), in GitLab 14.0.
More GitLab integrations
- Get the most out of the Checkmarx integration with GitLab
- Is DevOps for designers?
- Demo: GitLab + Jira + Jenkins
Cover image by Ryan Quintal on Unsplash
