XebiaLabs Gives You Control of Your Data with Folder-Level Configuration Management

| July 17, 2018 | 0 Comments

As an integral part of your software delivery pipelines, the XebiaLabs DevOps Platform allows you to define connections to other tools, products, and platforms that make up your DevOps toolchain. These configurations can be shared across teams and projects at your convenience, and they enable the DevOps Platform to do things like:

  • Monitor an artifact repository such as Nexus for new artifacts
  • Watch a Git or Subversion code repository for changes
  • Update tickets in a ticket management system such as JIRA
  • Fetch results from a code analysis tool such as Black Duck or SonarQube

Until recently, you could only define configurations globally; that is, any template or release in XL Release could use any configuration that existed in the system in its tasks and triggers.

In the XL Release user interface, you define and manage these shared configurations on the Settings > Shared configuration screen. Only users with the Admin global permission can access this screen and manage shared configurations.

XL Release

Take Control of Configuration Data

The recently-added “configuration at folder level” feature gives you more control over configuration data by allowing you to define configurations in the same folders where you create your release templates, and where you have granular control over who has permission to access them. A configuration that is defined at the folder level can only be used by the templates and releases in that folder and by its children.

XL Release

For example, if your organization only has one instance of JIRA, you would probably define it under Settings > Shared configuration so that every template in the system can refer to it. But if the Online Banking team and the Lending team store their code in different Git repositories, you would define those repositories in the Online Banking and Lending folders. This separate configuration capability ensures that the Online Banking and Lending teams cannot access each other’s configurations.

Benefits of Folder-Level Configuration Management

  • More flexibility in configuration management.It’s simple: you have more options for storing configuration data in the way that makes the most sense for your organization. Every organization has different needs, and XebiaLabs is flexible enough to support your use cases.
  • More sophisticated way to organize and manage configurations. Managing configuration data for hundreds of tools, platforms, and repositories across the enterprise in one place can be difficult. Grouping this data logically and storing it in the folders that teams are already using for their release templates makes it much more manageable.
  • More control over security for configuration management. Storing the configuration data for your DevOps toolchain in XL Release for automated task execution reduces the number of people who require access to those tools, which means your CI/CD infrastructure is inherently more secure. And storing configuration data at the folder enhances this security, as teams only see their own configurations, not those used by others.
  • Less work for administrators and more flexibility for teams. The Admin global permission is required to create, modify, or delete shared global configurations, so when you want to work with a global configuration, you need to ask an XL Release administrator for help. With folder-level configurations, administrators can retain control over the global configurations that many teams need to use, but they don’t have to do maintenance work for teams that have their own specific configurations.

“DevOps

11 Black Holes of DevOps: How Not to Get Lost in Outer Space

Check out this white paper to learn the 11 DevOps “black holes” you can easily get sucked into… and how to avoid them!

How Inheritance Works

When a configuration is defined in a folder, the templates and releases in that folder and in the folders that are children of that folder can use it. For example, let’s say I have this folder structure:

  • Lending
    • Personal Lending
    • Business Lending
      • Small Business Lending

I decide to define a Git repository called Lending App Repository in the Lending folder. That means that all of the templates in the Personal Lending, Business Lending, and Small Business Lending folders can use Lending App Repository in their triggers and tasks.

If I define a Git repository called Small Business App Repository on the Small Business Lending folder, only the templates in the Small Business Lending folder can use it. Of course, the templates in the Small Business Lending folder would still also be able to use Lending App Repository, because it’s inherited from the parent Lending folder.

What if, for some reason, you want to define Lending App Repository on both the Lending and the Small Business Lending folders, but with different properties for each folder? You would have to create a Lending App Repository configuration on each folder. There is no way for the configuration from one folder to “override” the configuration from another folder. Each configuration is a single entity.

Note: XL Release does not require configuration names to be unique, so be careful when naming things.

With powerful but flexible control of configuration data, you can scale the XebiaLabs DevOps Platform across your organization safely, knowing that each team only has access to the tools and platforms that they need for their own release templates. Take control of configuration data while ensuring that DevOps teams have what they need to increase task automation and orchestrate releases effectively.

Learn More


Amy Johnston

About the Author ()

Amy Johnston is a Senior Product Marketing Manager at XebiaLabs.