Platform One Party Bus Onboarding Process
| Team | Action |
|---|---|
| Customer engages the P1 Customer Success Team (CST). |
|
| Customer Success engages the Onboarding Team. | _ CST transfers the customer to the Party Bus Onboarding (PBO) team to schedule a formal Technical Fit to identify if your team is compatible with Party Bus. NOTE: Prior to sending an invite to the Tech Fit, an internal review of documentation is conducted by Party Bus Onboarding and TAMs (Technical Account Managers). _ After the Tech Fit, (refer to Step two, "Technical Fit" on the PB 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 Party Bus Onboarding (PBO) Point of Contact (POC). _ If your team is NOT compatible: _ The Onboarding 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. _ PB 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 "Pricing Quote" from the PB Onboarding page: _ BAMs reach to Customer Sponsor and Financial Management teams _ Track progress of MIPR, 7600s, Form 9s * MIPR received |
| PBO engages Customer/Product Team | _ The Onboarding team schedules creation of all your team member accounts on Gitlab, JIRA, Confluence and Mattermost. _ The Onboarding team schedules the team for a Training Workshop. * The Onboarding team transfers the team to the Mission DevOps team (MDO) for evaluation of the gitlab repos. |
| Mission DevOps (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 validate 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 COT Epic will be placed in the queue with a story for each requested project/pipeline. _ What is setup during the pipeline process? _ RDS (MySQL/Postgres). _ A pipeline for each project with a dockerfile at the root. _ A pipeline for each Package needed (if needed). - no dockerfile needed. * 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 Continuous Authority to Operate (C-ATO). Continuous means the product team onboarding with Party Bus understands that the application will be continuously monitored for security vulnerabilities. This means that if a critical vulnerability is found, the Cyber team 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 Platform One 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 Platform one provides. Additional onboarding options can be obtained from the Platform One Services site. If you would like to have your own Government Cloud instance, please engage Cloud One. Once verified as compatible with Party bus, the Customer Success team will obtain funds from the team and pass to the Onboarding team to continue the teams Party Bus journey.
Types of Product Team Scenarios:
- Full Party Bus Customer: Pipelines to be deployed to Platform One staging and production environments.
- Party Bus Staging Only: Pipelines to be deployed to Platform One staging only. a. This scenario can include deploying to Party Bus for staging and to ODIN for IL6 production deploys.
- Pipeline Only: Pipelines to be created and scanned, but are deployed to an external environment.
- Gitlab Repo Only: No pipelines, just a Gitlab repo to store code. Gitlab runners are disabled.
- Party Bus to Big Bang: Customer does a proof of concept on their application(s) while setting up their environment in Big Bang.
- 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 Customer Success has determined that they are potentially compatible with Party Bus through the initial technical intake process.
| Action | Assigned |
|---|---|
| Engages the Onboarding team to get them into JIRA onboarding queue through a Party Bus Onboarding (PBO) Epic. | Customer Success |
| Clones initial CSJSD data and creates a PBO epic to track teams progress during the onboarding process. | Customer Success |
| Schedules a formal Technical call to determine if the application's technical stack is compatible with what Party Bus supports. NOTE: An internal review of documentation is performed by Onboarding, Mission DevOps and PB Ops prior to Invite to Tech Fit email. | Onboarding (w/ MDO + PB Ops) |
| Initiates initial access for team POCs/Team Onboarding Supervisors. | Onboarding |
| Assists customer with access that requires a CAC. | Onboarding |
| Creates Razor Crest ticket to grant access to JIRA/Confluence. | Onboarding + Team POCs |
| Schedules a Workshop to provide initial Platform one Party Bus training. | Onboarding + Individual Users |
| Hand off to the Mission App DevOps (MDO) team by creating a COT epic to create the 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 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 Mission DevOps COT Epic Board and the team is now managed by the Mission DevOps Team (MDO). The MDO Team manages the creation of all staging and production pipelines in the IL2/IL4/IL5 environments. The Classified Ops team manages the SIPR/JWICS deployments addressed later in this document.
Product Team Prerequisite for a Staging Pipeline
TBD
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 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.
- Upon request, one RDS in a multi-tenant cluster is provided, unless alternative arrangements are made during the onboarding process. eg single-tenant
- Upon request, an S3 bucket is provided, unless alternative arrangements are made during the onboarding process.
- Each project being deployed to staging/production is counted as a pipeline.
- Each pipeline uses a Dockerfile at the root of each project to deploy to staging.
NOTE: Package pipelines do NOT require a dockerfile. - Gitlab-ci.yaml files are NOT allowed and will be deleted by the Mission DevOps team.
- 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 the team projects are ready for a Mission App DevOps 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 Mission DevOps once the Team Lead/Onboarding Supervisor has submitted a NEW Staging Pipeline Request ticket.
| Action | Description |
|---|---|
| Pipeline Setup | 1. Structure for pipeline is setup based upon defined rules with the Mission DevOps team. 2. The MDO team requires a dockerfile at the root of each pipeline project in order to setup the pipeline for each project. 3. SCA tools are setup: Fortify, 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 setup in a multi-tenant cluster. 2. S3 buckets are not required, but are provided if needed. 3. Communication with S3 is performed through IAM Roles forService Accounts (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 setup. 2. An initial team list is obtained. 3. Application parses the JWT token to provide authentication to their application. |
| Mission Bootstrap for Application | 1. Setup encrypted authorization setup. 2. Setup DNS with CNAP team. |
Pipeline Assistance Tickets
- Open a Pipeline Issues ticket for failed pipeline stages.
- Open a Pipeline Exception request ticket to whitelist CVE's from the dependency, sonarqube, twistlock and fortify stages.
- Open a new Pipeline Request ticket to request another pipeline be created for a new project added to your repo.
- Open a Staging Egress Request ticket to request outbound whitelisting.
- Open a Production Egress Request ticket to request outbound whitelisting.
- Open an Access Removal Request ticket to remove the access of a team member.
- Follow the steps in the How To: Onboard a New Product Team Member section to onboard a new team member.
- Open a CtF Request ticket to start your Certificate to Field process for Production Deploys.
- SD Elements access: Open the SDElements Account Request ticket.
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 the Cyber team and all stages in the staging deploy to 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/JWICS) and IL2/IL4/IL5 deploys. The MDO team only deploy to the IL2/IL4/IL5 environments. The two below tables describe the process for both types of production deploy requests.
- Open a CtF Request Ticket to start your Certificate to Field process for Production Deploys.
Mission DevOps Action: Deploy to IL2/IL4/IL5 Environment
| Action | Assigned |
|---|---|
| Verify which staging and production impact levels 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 |
| Cleans up all old pipeline-products branches and merges into master. | MDO DevOps |
| Prepares the production folder structure. | MDO DevOps |
| Notifies 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. | Cyber Team |
| Link the signed CtF letter to the Epic. | Cyber Team |
| Open a Production Deploy Request Ticket once the CtF is complete. | Product Team |
| Engage the Classified Ops team to request verification of funding. | Product Team |
| Verify the CtF was approved and which impact levels 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 |
| Cleans up all old pipeline-products branches and merges into master NOTE: Once the team branch is merged into master, all exceptions will have to be approved through an MR. | MDO DevOps |
| Prepare the SIPR or JWICS production folder structure(s). | MDO DevOps |
| Notifies the Classified Ops team through the CO story that the Production Deployment structure is ready. | MDO DevOps |
| Assign the COT Epic to the Classified Ops PM upon completion of the Production Deployment structure. | MDO DevOps |
| Engages the Classified Ops team to verify funding on the ODIN environment. | Product Team |
| Continues engagement with the Classified Ops 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 TeamLead/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 Platform One 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 Platform one user. Go back to Step #1 if you are not registered. If you are new to Platform One, 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, Fortify, Sonarqube, and ArgoCD access. NOTE: Users will need to navigate to SonarQube (<SecureLink text="IL2" url="https://sonarqube.il2.dso.mil" il="il2" /> | <SecureLink text="IL4" url="https://sonarqube.il4.dso.mil" il="il4" /> | <SecureLink text="IL5" url="https://sonarqube.il5.dso.mil" il="il5" />) and GitLab (<SecureLink text="IL2" url="https://code.il2.dso.mil" il="il2" /> | <SecureLink text="IL4" url="https://code.il4.dso.mil" il="il4" /> | <SecureLink text="IL5" url="https://code.il5.dso.mil" il="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 you 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 App Gate (IL2/IL4 newly as of spring 2023) and access is controlled by your application 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 Platform One account. All application URLs require being logged into App Gate. This means your team will need to purchase App Gate 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 . | Team PM/Lead |
| 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 display 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 Mission App DevOps Customer Onboarding and Tracking (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. Mission App DevOps communicate 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 | PB Sub-Team Ownership | Additional Information |
|---|---|---|
| CtF - Active | Cyber Applications Team | Teams that are currently working through the CtF process and answering SD Elements controls. |
| CtF - Completed | Cyber Applications Team | Teams with a completed CtF. The MDO PM will then validate the CtF documents and place in the MDO production deployment queue. |
| CtF - Queue | Cyber Applications Team | Teams that engaged the Cyber team about setting up CtF onboarding. |
Deployed to Staging and Production Platform One Environments
| Column on COT Board | PB Sub-Team Ownership | Additional Information |
|---|---|---|
| Deployed - Production | Mission App DevOps or Classified Ops | Teams with a CtF that are deployed to the production environment. |
| Deployed - Staging | Mission App DevOps | Teams with a CtF that are deployed to the Staging environment. |
| Follow-Up | Mission App DevOps PM | PM Follow-up to ensure team is compliant before being placed in the Pipeline Queue column. |
| MDO PM Review | Onboarding Mission App DevOps | 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 | PB Sub-Team Ownership | Additional Information |
|---|---|---|
| Offboard - Queued | Mission App DevOps Anchor | Mission App DevOps PM places in this queue with a due date for MDO anchors to remove Product team artifacts from Platform One. |
| Offboard - Completed | Mission App DevOps Anchor | Mission App DevOps anchor archives/deletes the below:_ GitLab Repos _ All SCA projects |
Staging Pipeline Statuses
| Column on COT Board | PB Sub-Team Ownership | Additional Information |
|---|---|---|
| Pipeline - In Dev | Mission App DevOps | Mission App DevOps team is working with the Product Team to actively build the pipelines. |
| Pipeline - Blocked | Mission App DevOps | DevOps may have started the pipeline but are in blocked status waiting for the Product Team to take action. |
| Pipeline Complete | Mission App DevOps | 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 | Mission App DevOps | 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 | PB Sub-Team Ownership | Additional Information |
|---|---|---|
| Prod - Deploy in Progress | Mission App DevOps | Teams with a CtF that are actively being worked by a DevOps for a Production deploy. |
| Prod - Deploy Queued | Mission App DevOps (IL2/IL4/IL5) Classified Ops (SIPR/JWICS) | Teams with a Signed CtF letter that are waiting in the queue to be deployed to Production. |
| Prod - Deploy Blocked | Mission App DevOps | Waiting on product team to fix their pipeline before the Mission DevOps (MDO) team can move forward with the production deploy request. Reasons:* Staging deploy is not GREEN. |
Waiting on Customer Action:
| Column on COT Board | PB Sub-Team Ownership | Additional Information |
|---|---|---|
| Waiting - Iron Bank | Mission App DevOps | _ 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 team for a CtF. |
| Waiting - Product Team | Mission App DevOps PM or Anchor | Onboarding 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
FAQs
Where do I get started?
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 Fortify?
Open a Pipeline Exception Request ticket .
How do I get access to JIRA/Confluence in another impact level?
Contact Support .