Skip to main content


Project description



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
  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
  name: MyLittlePony
    Entity: ACME
    admins: [robert]
    users: [alice, bob]
    readers: [eve]
  - name: Stable
    users: [carol, david]
  - name: Corral
    users: [carol]
  - name: Grooming
    admins: [alice]
    users: [david]
    - sonarqube:qualityprofile=css
    - technology: docker
      options: []
      remotes: []
    - technology: pypi
      options: []
      remotes: []
  - name: ABC
    - tracker=PONY
  testbooks: []
  - name: PONY
    admins: [bob]
    readers: [carol]

In the above example, we have three levels of access (admins, users, and readers), and the project will have associated resources in a set of domains (sources, teams, spaces, testbooks, and trackers).

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 instance, 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 ( 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

SPDX-License-Identifier: EPL-2.0

Project details

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distributions

No source distribution files available for this release.See tutorial on generating distribution archives.

Built Distribution

zabel-0.13.0-py3-none-any.whl (25.7 kB view hashes)

Uploaded Python 3

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page