Package: zabel
ZabelOverviewProjects, 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 ofmanaged 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 DefinitionsThere is one managed project definition per project, and it can evolve over time.A managed project definition has at least a name:apiVersion:zabel/v1kind:ManagedProjectmetadata:name:Project42This 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/v1kind:ManagedProjectmetadata:name:MyLittlePonylabels:Entity:ACMEDepartment:spec:globals:admins:[robert]users:[alice,bob]readers:[eve]sources:-name:Stableusers:[carol,david]-name:Corralusers:[carol]teams:-name:Groomingadmins:[alice]users:[david]options:-sonarqube:qualityprofile=cssrepositories:-technology:dockeroptions:[]remotes:[]-technology:pypioptions:[]remotes:[]spaces:-name:ABCoptions:-tracker=PONYtestbooks:[]trackers:-name:PONYadmins:[bob]readers:[carol]In the above example, we have three levels of access (admins,users, andreaders),
and the project will have associated resources in a set ofdomains(sources,teams,spaces,testbooks, andtrackers).Access rights can be specified at project level and refined on domains.Domains are representing tool(s).  For example,sourcesmay be a GitHub or GitLab
instance,teamsmay be an Artifactory+Jenkins+SonarQube toolchain, andspacescould 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 NutshellZabel 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 (Realmin Zabel parlance), you define the expected strategy,
conventions, domains, constraints, and Zabel will manage the rest for you.LicenseCopyright (c) 2019-2020 Martin Lafaix (martin.lafaix@external.engie.com) 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