MDO Preparing for the Pipeline Queue"
Introduction
Product Teams must complete certain tasks before Mission DevOps (MDO) can place their COT epic in the pipeline queue. Additional items are suggested, as they must be addressed eventually but do not bar pipeline implementation.
Hard Prerequisites
The following items must be completed before Mission DevOps will begin implementing a pipeline.
Actions
All users should self-register for the below services:
GitLab requirements:
the URL slug:
- Organization name: if applicable, e.g., platform-one, abms, and tron
- Team name
- Application name: this is a GitLab group and represents the application
- Repo/service name: this will be a GitLab project and corresponds with the service/deployment for a Docker image. For package-pipelines, this repo will result in an package/artifact that can be used by other pipelines/repos.
Remember: Organizations are comprised of many teams, which may each contain one or more apps. Each app may be comprised of one or more repositories, i.e. microservices, and all repositories under an application will be deployed in Kubernetes with the application's URL slug set as the namespace.
Diagram of example GitLab structure:
- Example URL slug:
- Verify that GitLab group (organization, team, app) and project (repository) names meet the following criteria:
- Contains between 3 and 18 characters, inclusive.
- Only contain lowercase characters, numbers, and dashes.
- Must start with an alphabetical character
All users requiring SonarQube access should each log into SonarQube (IL2 | IL4 | IL5 ) to initialize their account, which will then be associated by MDO to the relevant projects when setting up the pipelines.
Verify that code is checked into the repo's default branch. Party Bus pipelines are configured to only run the full pipeline on the default branch. Other protected branches can run the scan and build jobs, but cannot deploy.
Verify Razor Crest has granted the Product Team access to respective Atlassian and GitLab groups.
Verify each repo only uses one package manager. Party Bus does not support multi-language repositories. All code in a repository must be the same programming language. and use the same framework. The pipeline templates are set up specifically to build, scan, and deploy one language and framework.
Verify each repo uses a tech stack that is currently supported. Images/software versions as of 2024-Apr-11 are indicated, but are subject to change. This page may not be up-to-date; recommended versions are dependent on Iron Bank images. If a different version is needed, verify it is supportable and let us know when requesting a pipeline.
| Tech stack/Package Manager | Image | Deployment Pipeline Support | Package Pipeline Support | Notes |
|---|---|---|---|---|
| cpp | registry.il2.dso.mil/platform-one/devops/pipeline-templates/pipeline-job/ubi8-cpp-tools-bundle:8.8.0 | YES | NO | |
| dotnet | registry1.dso.mil/ironbank/redhat/dotnet-core/dotnet-sdk-6.0:6.0 | YES | YES | |
| go | registry1.dso.mil/ironbank/google/golang/ubi9/golang-1.21:1.21.8 | YES | YES | |
| gradle | registry1.dso.mil/ironbank/opensource/gradle/gradle-jdk11:8.1 | YES | YES | |
| maven | registry1.dso.mil/ironbank/opensource/maven/maven-openjdk-11:3.8.6 | YES | YES | |
| npm/yarn | registry1.dso.mil/ironbank/opensource/nodejs/nodejs16:16.20.2 | YES | YES | |
| php | registry.il2.dso.mil/platform-one/devops/pipeline-templates/base-image/php74-composer:7.4.29 | YES | YES | based on composer |
| python | registry.il2.dso.mil/platform-one/devops/pipeline-templates/pipeline-job/python39-builder:3.9.18 | YES | YES | based on pip requirements.txt; supports pytest and coverage unit testing |
| ruby | registry.il2.dso.mil/platform-one/devops/pipeline-templates/pipeline-job/ruby27-builder:2.7.6 | YES | NO | based on rails; supports rspec and minitest unit testing |
Details for COT Description
In a comment on the COT, provide the following information:
- The staging environment (choices: IL2, IL4, IL5). This will be the same IL as the source code repo.
- The production environment(s) (choices: IL2, IL4, IL5, JWICS, SIPR)
- List of users that need access to the SCA tools (Fortify and SonarQube). These users will be able to view scan results as well as leave comments on findings (these are used for justification before we whitelist them). Users not granted access to the Twistlock or Anchore UI (failures are only viewable in pipeline job output). For each user, requiring access, provide the following:
- Platform One username
- First and last name
- Email address
Soft Prerequisites
The following items will need be addressed eventually, but their lack of completion does not bar pipeline implementation.
- If the repository is using the npm or yarn pipeline template, define the following scripts in package.json:
- test:unit (runs in unit tests job)
- lint (runs in lint job)
- test:e2e-ci (runs in e2e tests job if using cypress)
- If the repository will create a Docker image, ensure the Dockerfile is properly configured
- The Dockerfile is located at the root of the repository.
- Lint the Dockerfile using hadolint, and fix all warnings or errors.
- Ensure the Dockerfile contains no install commands (e.g., pip install, apt-get install, dnf, yum, among others), as Platform One prohibits egress in the Dockerfile. Dependencies are installed through the pipeline's build stage, and should be copied into the image after they have been scanned.