Projects, in the sense of a group of people working together over a period of time and intending to achieve a particular purpose, are started every day, exist everywhere.
Initiating those projects, if they rely on some sort of software infrastructure, can be a tedious job. Configuring the necessary tools, creating the necessary resources, links, permissions, accesses and so on is time consuming and error prone.
Projects evolve over time, too. New needs may arise, new tools may be added, old tools may be removed or replaced. The group of people may shrink or grow. And maybe we pay per seat for some of those tools.
So, how do we manage those things?
Zabel introduces the notion of managed project definitions, which are text files (YAML or JSON documents) that describe projects scaffoldings. They can be kept in a version control system.
Managed Project Definitions
There is one managed project definition per project, and it can evolve over time.
A managed project definition has at least a name:
apiVersion: zabel/v1 kind: ManagedProject metadata: name: Project42
This can be enough if all your projects have the same layout, with, say, a source code repository, a set of pipelines on your CI/CD toolchain, and some documentation space.
Zabel will use this managed project definition to create the necessary resources and configure them.
In most contexts, though, not all projects have the same layout, and you may have to manage user accesses and license seats.
So, a more common managed project definition may look like the following:
apiVersion: zabel/v1 kind: ManagedProject metadata: name: MyLittlePony labels: Entity: ACME Department: spec: globals: admins: [robert] users: [alice, bob] readers: [eve] sources: - name: Stable users: [carol, david] - name: Corral users: [carol] teams: - name: Grooming admins: [alice] users: [david] options: - sonarqube:qualityprofile=css repositories: - technology: docker options:  remotes:  - technology: pypi options:  remotes:  spaces: - name: ABC options: - tracker=PONY testbooks:  trackers: - name: PONY admins: [bob] readers: [carol]
In the above example, we have three levels of access (
and the project will have associated resources in a set of domains (
Access rights can be specified at project level and refined on domains.
Domains are representing tool(s). For example,
sources may be a GitHub or GitLab
teams may be an Artifactory+Jenkins+SonarQube toolchain, and
spaces could be a Confluence server.
This is just an example, though. You may need finer or coarser access levels, and what domains you need and what tools they rely on are of course specific to your context.
In a Nutshell
Zabel provides the necessary infrastructure to manage an evolving collection of managed project definitions.
One deployment of Zabel can manage multiple contexts, each context having its own domains, access level definitions, conventions, ...
For each context (Realm in Zabel parlance), you define the expected strategy, conventions, domains, constraints, and Zabel will manage the rest for you.
Copyright (c) 2019-2020 Martin Lafaix (firstname.lastname@example.org) and others This program and the accompanying materials are made available under the terms of the Eclipse Public License 2.0 which is available at https://www.eclipse.org/legal/epl-2.0/ SPDX-License-Identifier: EPL-2.0
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.