MCaaS Jenkins Structure and Governance Tier

Tenant Git Hierarchy

Each tenant will have a Github Enterprise organization where tenant administrators will have full permissions over. To enforce Jenkins Templating Engine (JTE) governance model, we require each application code repository to have defined prefixes. For more information about the JTE governance model, please read the sections below. The repository will be at the service level with short code prefixes of its corresponding module and application, e.g. MOD-APP-Svc. Below is a mapping of MCAAS topology to git hierarchy.

MCAAS Topology	Git Hierachy	Sample Prefix Filter	Method of Creation
Tenant	Github Organization	N/A	Manual/Auto through DSL Script
Module	Github Repository w/ Module Prefix	mod-*	Manual/Auto through DSL Script
Application	Github Repository w/ Module & Application Prefix	mod-app-*	Manual/Auto through DSL Script

MCAAS Tenant Jenkins Instance

MCAAS uses a single multi-tenant Jenkins cluster for tenants’ application CI/CD Jenkins jobs. This Jenkins Instance can be signed into using your existing FCS account here: https://jenkins-mcaas.helix.gsa.gov/

JTE Governance Hierarchy

Below is a table showing mapping of MCAAS topology to the Jenkins hierarchy.

MCAAS Topology	Jenkins Hierachy
Tenant	Tenant Folder
Module	Module Folder
Application	Github Organization Job

Each tenant will have a tenant folder on the Jenkins root. Each module belonging to the tenant will have its own folder under the tenant’s folder. Each application will be Jenkins Github Organization job which will have repository filters on module and application, e.g. MOD-APP-*. Each service belonging to the application mapps to a job pipeline created automatically by the module level Jenkins Github Organization job. The branches of each service will fall under the service job pipeline.

Below is a diagram showing the hierarchy described above.

JTE/Jenkins Config Files

A tenant’s Jenkins configuration can be implemented at each tier of the Jenkins hierarchy pictured above. The Jenkinsfile and Pipeline Configuration will be initially set at the tenant directory level and will point to the tenant-jenkins-global-config repository in the MCaaS Github Organization. This global configuration will be provided to all tenants and contain a well architected, MCaaS pipeline (following ideal Gitflow methodology) and contain mandatory security libraries, steps, and pipeline primitives.

Any tenant that wishes to deviate from this global pipeline will work with the MCaaS team to create a new Jenkinsfile in their tenant-jenkins-config repository and pipeline_config.groovy within their tenant Github organization. This Jenkinsfile will supersede the tenant-jenkins-global-config Jenkinsfile provided by the MCaaS Cloud Engineers, but the pipeline_config.groovy will only merge with or override the values of the tenant-jenkins-global-config pipeline_config.groovy. This custom configuration can be performed at the module, app, and microservice level which allows for more granular customization of a tenant’s CI/CD process.

Below is a table which outlines the JTE Hierarchy, associated files and locations, as well as responsibility:

Jenkins/JTE Hierarchy	File Name & Path (Org/Repo/Path)	Responsibility
Tenant Folder	<p>tenant-jenkins-config/Jenkinsfile</p>tenant-jenkins-config/pipeline_config.groovy	MCaaS Cloud Engineers
Module Folder	<p>tenant-jenkins-config/mod/Jenkinsfile</p> tenant-jenkins-config/mod/pipeline_config.groovy	Shared (MCaaS Cloud Engineers & Tenant Developers)
Application Github Org	<p><tenant-app-repo>/Jenkinsfile</p> <tenant-app-repo>/pipeline_config.groovy	Shared (MCaaS Cloud Engineers & Tenant Developers)

Pipeline Libraries

Under the Jenkins Templating Engine framework, new pipeline functionality isn’t written directly to the Jenkinsfile but incorporated through the development of modular, reusable pieces of code, consolidated into pipeline libraries. These pipeline libraries can be referenced and called by adding them to the pipeline_config.groovy file. A developer who wishes to add new functionality to their Jenkins pipeline should do this by cloning the MCaaS/Pipeline-Libraries repository to their local machine, creating a branch from the development branch, and adding a new directory with new library code. When the library is ready, the developer can open a pull-request to merge their branch into the development branch. The MCaaS cloud engineers will review this pull request and work with the tenant developer to incorporate this code into the larger ecosystem. This allows for new functionality to be created and shared across the MCaaS platform, saving development time and reducing redundancy. All tenant pipelines will reference the MCaaS/Pipeline-Libraries repository at the Tenant folder level configuration in the Jenkins/JTE hierarchy.

JTE Config File Hierarchy

As stated previously, a tenant’s Jenkinsfile may supersede the Jenkinsfile at a higher level in the governance hierarchy. For example, a Jenkinsfile located in the microservice repository would supersede a Jenkinsfile at the module level. A tenant pipeline_config.groovy will only merge with or override values from the tenant-jenkins-global-config pipeline_config.groovy maintained by the MCaaS cloud engineers. This is to ensure that mandatory components, such as security tooling and shared FCS API endpoints in the CI/CD process are incorporated into the build pipelines of every tenant.

Below is a diagram of the JTE Governance File Structure and Hierarchy: