Platform One Party Bus Onboarding Process

Team	Action
Customer engages the P1 Customer Success Team (CST).	Ascertain compatibility with Party Bus or Big Bang. The CST identifies through a technical intake discussion that you may be compatible with Party Bus = "CSGO" meeting. The CST creates/provides a Rough Order of Magnitude (ROM) estimate of their Party Bus requirement(s) if requested by customer. The CST establishes a source of truth Customer Success Jira Service Desk (CSJSD) ticket/record for customer to refer to during your customer journey. The CST provides overview of the entire onboarding process.
CST engages the Party Bus Onboarding (PBO) Team.	The CST transfers the customer to the PBO Team to schedule a formal Technical Fit session to identify if your team is compatible with Party Bus. NOTE: Prior to sending an invitation to the Technical Fit, an internal review of documentation is conducted by PBO and Technical Account Managers (TAMs). After the Technical Fit, (refer to Step #2, "Attend a Technical Fit Session" on the Party Bus Onboarding page): If your team is compatible: _ CST will provide a quote for services. Once accepted, you will go through the funding process and be assigned a Business Account Manager (BAM) and PBO Point of Contact (POC). If your team is NOT compatible: _ The PBO Team refers you back to CST to schedule a call with the Big Bang team for a potential fit. _ If not a fit, PBO refers customer to Party Bus value stream lead (estimated 3 weeks) _ Schedule enhanced Solution Engineering/Architecture Session to detail out hard system requirements, above baseline Service Catalog features, and discuss funding activities. _ Party Bus leadership coordinates cross-value stream services and approvals (CNAP, Iron Bank, Cyber). _ Leadership reviews above baseline services and works with CST to cost out appropriately.
Business Account Manager (BAM) coordinates funding	Refer to Step #3 "Assess Price Quote and Complete Contract" from the Party Bus Onboarding page: BAMs reach out to Customer Sponsor and Financial Management teams. Track progress of MIPR, 7600s, Form 9s. Receive MIPR.
PBO engages customer/product team	The PBO Team schedules creation of all your team member accounts on GitLab, Jira, Confluence, and Mattermost. The PBO Team schedules your team for a training workshop. The PBO Team transfers your team to the Mission DevOps (MDO) Team for evaluation of the GitLab repos.
MDO engages the product team.	This is the team that will be creating your pipelines and supporting you through tickets during your Party Bus journey. Prerequisite check - Before the pipeline(s) can be created: Monolithic repos are prohibited! A valid Dockerfile at the root of each project must exist for all deployment pipelines. A package pipeline does not require a Dockerfile at the root of the project. The application as a whole and all projects that are part of the application must follow Cyber Guidelines. Open a ticket for each requested pipeline: New Pipeline Request Form The Customer Onboarding and Tracking (COT) Epic will be placed in the queue with a story for each requested project/pipeline. What is set up during the pipeline process? Relational Database Service (RDS) (MySQL/Postgres). A pipeline for each project with a dockerfile at the root. A pipeline for each Package needed (if needed) - no dockerfile required. S3 buckets (if needed).

Party Bus End-to-End Process

Party Bus provides CI/CD DevSecOps pipelines in a secure environment for hosting applications. By following the Party Bus opinionated guidelines, teams inherit the Party Bus Authority to Operate (ATO). If a critical vulnerability is found, the Cyber Application Team (CAT) will work with the product team to ensure the identified vulnerability is quickly fixed to prevent removing the application from the Party Bus architecture.

Step 1: Party Bus Customer Success Team

This is the first engagement with P1 to ascertain whether a potential new product team is compatible with Party Bus or Big Bang. Please review the Platform One Products and Services site for an overview of the services P1 provides and additional onboarding options. If you would like to have your own Government Cloud instance, please engage Cloud One. Once verified as compatible with Party Bus, the CST will obtain funds from the team and pass to the PBO Team to continue your team's Party Bus journey.

Types of Product Team Scenarios:

1. Full Party Bus Customer: Pipelines to be deployed to P1 staging and production environments.
2. Party Bus Staging Only: Pipelines to be deployed to P1 staging only. a. This scenario can include deploying to Party Bus for staging and to the OE Data Integration Network (ODIN) for Impact Level (IL) 6 production deploys.
3. Pipeline Only: Pipelines to be created and scanned, but are deployed to an external environment.
4. Gitlab Repo Only: No pipelines, just a GitLab repo to store code. GitLab runners are disabled.
5. Party Bus to Big Bang: Customer does a proof of concept on their application(s) while setting up their environment in Big Bang.
6. Party Bus to Cloud One: Customer does a proof of concept on their application(s) while setting up their environment in Cloud One.

Step #2: Party Bus Onboarding Team

Product teams move to the onboarding queue when CST has determined that they are potentially compatible with Party Bus through the initial technical intake process.

Action	Assigned
Engages the PBO Team to get them into the Jira onboarding queue through a PBO Epic.	CST
Clones initial CSJSD data and creates a PBO Epic to track team's progress during the onboarding process.	CST
Schedules a formal technical call to determine if the application's technical stack is compatible with Party Bus. NOTE: An internal review of documentation is performed by PBO, MDO, and Party Bus Ops prior to email invitation to Technical Fit.	PBO (w/ MDO + Party Bus Ops)
Initiates initial access for team POCs/team onboarding supervisors.	PBO
Assists customer with access that requires a Common Access Card (CAC).	PBO
Creates Razor Crest ticket to grant access to Jira/Confluence.	PBO + Team POCs
Schedules a workshop to provide initial P1 Party Bus training.	PBO + Individual Users
Hands off to the MDO Team by creating a COT Epic to create staging pipelines.	Onboarding

Step #3: Onboarding Team Opens a GitLab Group Creation Process

This section describes the GitLab group creation process and what the customer can expect. When you see "Team Lead/Onboarding Supervisor," that is what is expected of your team.

What Happens Next?

The team is assigned a COT Epic that will follow you through your Party Bus journey.

Action	Assigned
A COT Epic exists for your team to provide a centralized place to reference all your tickets and stories throughout your Party Bus journey. The COT Epic is for anything related to your pipeline work. * Any access requests should always be opened by your onboarding supervisor.	Onboarding Supervisor
Once the Pipeline is verified and ready, the COT Epic is placed in Pipeline Queued Status.	MDO Product Manager (PM)
The COT Epic is placed in Pre-requisite status until the GitLab repos are Cyber compliant Example Dockerfiles Example Application Setup	Team Developers
The team lead/onboarding supervisor opens a New Staging Pipeline Request Ticket when ready for pipeline creation.	Onboarding Supervisor

Step #4: Pipeline Creation Process

The onboarding process is finished. An Epic is created on the MDO COT Epic Board and your team is now managed by the MDO Team. The MDO Team manages the creation of all staging and production pipelines in the IL2/IL4/IL5 environments. The Classified Ops (CO) team manages the SIPR/AFSCI deployments addressed later in this document.

Product Team Prerequisite for a Staging Pipeline

Reference the MDO Preparing for the Pipeline Queue article to review prerequisites for a pipeline.

MDO Staging Pipeline Creation Process

This section describes what happens once the product team has an Epic on the COT Epic Board and a GitLab group created. If requested, each application comes with an RDS in a multi-tenant cluster and/or an S3 bucket with connection through IAM Roles for Service Accounts (IRSA).

Things To Know

The below assumes a pipeline for deployment. An alternative pipeline is for packages that can be reused across multiple projects. Package pipelines do not require a Dockerfile.

1. Choose your GitLab group and project names carefully before creating a pipeline. These names cannot be changed later, as they are used to define multiple tooling projects and internal Kubernetes naming across the application, image bootstrap, and manifest YAML. Party Bus does not support renaming after the fact, so you would have to recreate the application and pipelines from scratch.
2. Upon request, one RDS in a multi-tenant cluster is provided, unless alternative arrangements are made during the onboarding process (e.g., single-tenant).
3. Upon request, an S3 bucket is provided, unless alternative arrangements are made during the onboarding process.
4. Each project being deployed to staging/production is counted as a pipeline.
5. Each pipeline uses a Dockerfile at the root of each project to deploy to staging.
   NOTE: Package pipelines do NOT require a Dockerfile.
6. Gitlab-ci.yaml files are NOT allowed and will be deleted by the MDO Team.
7. Please follow the guidelines in the Preparing the Pipeline document to understand the pipeline process.

Staging Pipeline Explanation

This section describes the actions that are taken once your team projects are ready for a MDO Team member to create staging pipelines for a deployable application. These steps are not for a package pipeline that can be used across multiple projects. These are actions by the MDO Team once the team lead/onboarding supervisor has submitted a NEW Staging Pipeline Request ticket.

Action	Description
Pipeline Setup	1. Structure for the pipeline is set up based on defined rules with the MDO Team. 2. The MDO Team requires a Dockerfile at the root of each pipeline project in order to set up the pipeline for each project. 3. Static Code Analysis (SCA) tools are setup: GitLab SAST, Twistlock, and SonarQube.
Manifest Repo Setup	1. Kubernetes structure for creating authentication token, RDS, S3, and other artifacts.
RDS/S3 Setup	1. Postgres or MySQL RDS set up in a multi-tenant cluster. 2. S3 buckets are not required, but are provided if needed. 3. Communication with S3 is performed through IRSA. 4. Product teams do not have direct access to their S3 bucket. Communication to S3 is done through IRSA in their application.
Keycloak Structure Setup	1. Keycloak group structure is set up. 2. An initial team list is obtained. 3. Application parses the JSON Web Token (JWT) token to provide authentication to their application.
Mission Bootstrap for Application	1. Set up encrypted authorization. 2. Set up Domain Name System (DNS) with CNAP Team.

Pipeline Assistance Tickets

1. Open a Pipeline Issues ticket for failed pipeline stages.
2. Open a Pipeline Exception request ticket to whitelist Common Vulnerabilities and Exposures (CVEs) from the dependency, Sonarqube, Twistlock, and GitLab SAST stages.
3. Open a new Pipeline Request ticket to request another pipeline be created for a new project added to your repo.
4. Open a Staging Egress Request ticket to request outbound whitelisting.
5. Open a Production Egress Request ticket to request outbound whitelisting.
6. Open an Access Removal Request ticket to remove the access of a team member.
7. Follow the steps in the How To: Onboard a New Product Team Member section to onboard a new team member.
8. Open a CtF Request ticket to start your Certificate to Field (CtF) process for production deploys.
9. SD Elements access: Open a SDElements Account Request for SD Elements access.

NOTIFICATION

DevOps follows either the Staging Deploy or the Production Deploy process based upon which swim lane the Epic is placed in.

Applications must pass the staging pipeline and be cleared to deploy to production through the CtF process.

MDO Production Deploy Process

Prerequisites:

• All production deploys require a signed CtF letter from CAT, and all stages in the staging deploy must pass and show GREEN before being allowed to deploy to any production environment. This means that all stages are set to allow_failures = false. There are two types of production deploys: Classified (SIPR/AFSCI) and IL2/IL4/IL5 deploys. Only the MDO Team deploys to the IL2/IL4/IL5 environments. The two tables below describe the process for both types of production deploy requests.
• Open a CtF Request Ticket to start your CtF process for production deploys.

Mission DevOps Action: Deploy to IL2/IL4/IL5 Environment

Action	Assigned
Verify which staging and production ILs the team has paid for and which projects are approved to deploy on their CtF letter and funding documentation.	MDO PM
Attach signed CtF letter to Epic.	MDO PM
Verify Cyber/CtF story is linked to Epic.	MDO PM
Create a Production Deploy story, link to the Epic and place in Selected for Development status.	MDO PM
Place the Production Deployment Epic in Prod - Deploy Queued status.	MDO PM
Set a due date to start the production deploy no later than 1 week from request.	MDO PM
Verify the staging deploy has allow_failures = false for ALL stages.	MDO DevOps
Execute the pipeline and verify all stages are passed and GREEN.	MDO DevOps
Open a ticket with comments for each SCA finding .	Product Team
Clean up all old pipeline-products branches and merge into default.	MDO DevOps
Prepare the production folder structure.	MDO DevOps
Notify the product team through Epic that the production deploy is complete and provides a link to the Pipeline Basics article for reference.	MDO DevOps

Mission DevOps Action: Deploy to a Classified Environment

Action	Assigned
Place the Epic in CtF - Completed Status.	CAT
Link the signed CtF letter to the Epic.	CAT
Open a Production Deploy Request Ticket once the CtF is complete.	Product Team
Engage the CO Team to request verification of funding.	Product Team
Verify the CtF was approved and which ILs were approved for deployment.	MDO PM & DevOps
Verify ALL stages in the staging deploy has allow_failures = false and all stages pass with GREEN.	MDO PM & DevOps
Clean up all old pipeline-products branches and merges into default NOTE: Once the team branch is merged into default, all exceptions will have to be approved through a merge request.	MDO DevOps
Prepare the SIPR or AFSCI production folder structure(s).	MDO DevOps
Notify the CO Team through the CO story that the Production Deployment structure is ready.	MDO DevOps
Assign the COT Epic to the CO PM upon completion of the Production Deployment structure.	MDO DevOps
Engage the CO Team to verify funding on the ODIN environment.	Product Team
Continue engagement with the CO Team during the IL6 deployment.	Product Team

Onboarding a New Team Member or Customer

How To: Onboard a Team Member

This section describes what actions the team lead/onboarding supervisor takes to onboard a new team member after the initial list of users have been granted access.

Action	Assigned
Scenario 1: Brand NEW user. Step #1: Register as a P1 user. IL2/IL4/IL5 Product Team access guide Step #2: The team lead/onboarding supervisor opens an Application Request form to add new team members. This action makes a request to grant ILX GitLab, ILX Atlassian, and ILX Mattermost Keycloak groups for basic tool access. *Add multiple team members to one ticket if needed. ASSUMPTION: The Application Request form assumes you are a valid registered P1 user. Go back to Step #1 if you are not registered. If you are new to P1, engage your team lead/onboarding supervisor to be granted the ILX GitLab/Atlassian/Mattermost Keycloak groups for basic membership access. Step #3: Open an Add/Remove User Access form to grant users access to ILX staging/production sites, GitLab Sast, Sonarqube, and ArgoCD access. NOTE: Users will need to navigate to SonarQube (IL2 IL4 IL5) and GitLab (IL2 IL5) to show up in the user list before they can be granted access.	Team Lead/Onboarding Supervisor
Scenario 2: Unapproved Funding If a team does not have proof of funding, they can submit a 2875 via aflcmc.hncx.helpdesk@us.af.mil](mailto:AFLCMC.HNCX.Helpdesk@us.af.mil) and the Razor Crest will review it or fill out an [IL2 Access Request form.	Product Team Lead
Scenario 3: Request Team Lead/Onboarding Supervisor Change If your team does not have a team lead/onboarding supervisor, fill out the Add/Remove Onboarding Supervisor Form.	Existing Team Lead/Onboarding Supervisor Onboarding Team MDO Team

How To: Onboard a New Developer

Action	Assigned
Set up a new P1 user by following the instructions in the SSO Setup document.	Onboarding Supervisor
The onboarding supervisor ONLY opens an Application Access Ticket to grant Mattermost, Jira, Confluence, GitLab, and staging/production URL access to new users.	Onboarding Supervisor
Open the Add/Remove User Access Ticket to grant access to all the developer tools needed to execute and manage a CI/CD pipeline.	Onboarding Supervisor

How To: Onboard a NEW Customer for Access to your Staging or Production URL

IL2/IL4/IL5 applications are behind AppGate and access is controlled by your application's custom roles and/or granting via keycloak. This means that a customer must have the IL4 Authorized Keycloak group assigned. The IL4 Authorized Keycloak group is AUTO assigned when a use plugs in their CAC and registers a P1 account. All application URLs require being logged into AppGate. This means your team will need to purchase AppGate licenses and JSD seats for each of your customers to access your site. Follow the steps in the How To: Onboard a New Product Team Member section of this document.

Action	Assigned
Set up a new P1 user by following the instructions in the SSO Setup document.	Onboarding Supervisor
The onboarding supervisor ONLY opens an Application Access Ticket to grant Mattermost, Jira, Confluence, GitLab, and staging/production URL access to new users.	Onboarding Supervisor

How To: Offboard a Product Team Member

This section describes how to reduce or remove a team members' access to specific resources.

Action	Assigned
Request the removal of access for a member leaving the team by opening a Remove Access Ticket . Add multiple team members to one ticket if needed.	Team PM/Lead
Update the COT Epic to reflect the new contacts/users that need notification through the Party Bus journey.	Team PM/Lead

How To: Add/Remove Gitlab Repo Members

This section describes the steps necessary for repo owners to manage membership access to the GitLab group/sub groups/projects.

ASSUMPTION:
Members have been granted to the ILX GitLab Keycloak group per the instructions in the How To: Onboard a New Product Team Member section.
Members MUST have already navigated to GitLab (IL2 | IL4 | IL5 ) to display in the member list. Do not invite members until they are displayed in the member list!

Step	Action
1	Navigate to your repo URL. (e.g., https://code.ilx.dso.mil/platformone/products/gitlab-group-name)
2	Click Subgroup information in the upper left:
3	Choose members.
4	Grant members _reporter, developer, maintainer, or owner access. NOTE: GitLab e-mails are disabled in IL2/IL4/IL5.

Appendices

COT Epic Explanation of Status

Below is an explanation of the statuses on the MDO COT Kanban board. Each product team is granted READ access to their Epic and can monitor the progress of their staging and production deploys through this Kanban board. All tickets and stories opened by the customer are linked to the COT Epic to centralized all Party Bus interactions for a specific team. The MDO Team communicates primarily through the Epic so all communication is recorded in one central location and to avoid any miscommunication. Technical conference calls are scheduled if needed.

Certificate to Field (CtF)

Column on COT Board	Party Bus Sub-Team Ownership	Additional Information
CtF - Active	CAT	Teams that are currently working through the CtF process and answering SD Elements controls.
CtF - Completed	CAT	Teams with a complete CtF. The MDO PM will then validate the CtF documents and place them in the MDO production deployment queue.
CtF - Queue	CAT	Teams that engaged CAT about setting up CtF onboarding.

Deployed to Staging and Production P1 Environments

Column on COT Board	Party Bus Sub-Team Ownership	Additional Information
Deployed - Production	MDO or CO	Teams with a CtF that are deployed to the production environment.
Deployed - Staging	MDO	Teams with a CtF that are deployed to the staging environment.
Follow-Up	MDO PM	PM follows up to ensure team is compliant before being placed in the Pipeline Queue column.
MDO PM Review	Onboarding MDO	Onboarding: Providing final documentation per the Onboarding resources. Mission App DevOps: Verification that all artifacts and required information have been provided per the Onboarding resources.

Offboard Customers

Column on COT Board	Party Bus Sub-Team Ownership	Additional Information
Offboard - Queued	MDO Anchor	Mission App DevOps PM places in this queue with a due date for MDO anchors to remove product team artifacts from P1.
Offboard - Completed	MDO Anchor	Mission App DevOps anchor archives/deletes the below: GitLab repos All SCA projects

Staging Pipeline Statuses

Column on COT Board	Party Bus Sub-Team Ownership	Additional Information
Pipeline - In Dev	MDO	Mission App DevOps Team is working with the product team to actively build the pipelines.
Pipeline - Blocked	MDO	DevOps may have started the pipeline but are in blocked status waiting for the product team to act.
Pipeline Complete	MDO	Teams that have a full pipeline but are not deployed to the staging environment yet. Teams may need to still work through SCA findings before deploying to staging.
Pipeline - Queue	MDO	Teams in the backlog waiting to have their requested pipeline to be assigned to a Mission App DevOps.

Production Deployment Statuses

Column on COT Board	Party Bus Sub-Team Ownership	Additional Information
Prod - Deploy in Progress	MDO	Teams with a CtF that are actively being worked by a DevOps for a production deploy.
Prod - Deploy Queued	MDO (IL2/IL4/IL5) CO (SIPR/AFSCI)	Teams with a signed CtF letter that are waiting in the queue to be deployed to production.
Prod - Deploy Blocked	MDO	Waiting on product team to fix their pipeline before the MDO Team can move forward with the production deploy request. Reasons: Staging deploy is not GREEN.

Waiting on Customer Action:

Column on COT Board	Party Bus Sub-Team Ownership	Additional Information
Waiting - Iron Bank	MDO	Waiting on Iron Bank to create custom images for the customer. Once ready, the MDO Team will update the customers manifests to deploy to staging. The next step is for the team to engage the CAT for a CtF.
Waiting - Product Team	MDO PM or Anchor	PBO and Mission App Team adds Epics to this column when they are not ready to be placed in the Pipeline - Queue column. Reasons: No GitLab repo, has a mono repo, repo needs to comply with Cyber requirements. Team is unresponsive.

Training

• Self Learning Videos
• Galvanize Platform One Workshops

FAQs

Where do I get started?

• Contact Customer Success .

How do I request a new service or pipeline?

• Open a New Pipeline Request ticket .

When do I start the CtF process?

• Open a Service Desk Ticket .

How do I add/onboard team members to Party Bus?

• For more information, refer to this document: MDOE - Party Bus - Product Team Internal Access.

I'm stuck. How do I get help with my pipelines?

Open a Service Desk ticket .

How do I get a CVE whitelisted for Trufflehog, Sonarqube, Twistlock, or GitLab SAST?

Open a Pipeline Exception Request ticket .

How do I get access to Jira/Confluence in another IL?

Contact Support .

References

• Party Bus Service Catalog
• App Gate Instructions
• MDO Announcements
• Open a Mission App Ticket