Aircraft cargo loading and weight and balance for the US Air Force
View live · Report Bug

Levels is a full stack web app that manages aircraft cargo loading and weight and balance for the US Air Force's load masters and maintenance.

The first and second iterations were built with tech stacks that could not be accredited and deployed to the Air Force network:

1. 5 Level Native Android
2. Five Level Flutter
3. Levels - UI Repo and API Repo

Levels, the third iteration, is deployed and accredited under the Department of Defense's DevSecOps initiative: Platform One

The frontend service has two main components. The dashboard and the admin portal.

The dashboard is used for configuring a cargo load to perform aircraft weight and balance.

The admin portal is used for performing CRUD operations on users, aircraft, configurations, and cargo.

• Offline persistance of the dashboard
• Near real time sync between the dashboard and the server while updating offline cache
• Real time admin portal

The API is a Restful interface that manages CRUD operations against multiple aircraft and user roles.

• JWT based user roles for each aircraft
• Local memory cache of common routes
• Logging

The UI and API are deployed to Platform One's mission bootstrap cluster. It lives behind an ISTO auth service that can use 2FA or a smart card.

• TypeScript
• Create React App
• Zustand
• Ant Design

• Postgres
• Express
• Prisma
• TypeScript

P1 is the Department of Defence DevSecOps initiative to deploy and accredit cloud native apps. Read more.

Pipelines are initially built in conjunction with the app team, and later managed by the DevSecOps team. Levels has separate pipelines for the frontend and backend service located here. They each use GitLab yml files to configure how each pipeline is run.

Each service's pipeline stages must pass before a production release can be made. This is a high level overview of each stage.

More info about each stage can be found here. Also, it may be helpful to enroll in the "Party Bus" to get more information about the stages and how they tie into accreditation.

Platform One standardizes certificate to field under the following conditions:

• Services are containerized using hardened images from the Iron Banks registry
• Unit tests are written with 80% line coverage
• XP development
• Usage of Platform One's ISTO Auth service
• Adhering to security standards under SD Elements, Fortify, Sonarqube, and limiting CVEs
• Passing pipelines

The current certificate to field (CtF) must be renewed once a year beginning June 24 2022, or when a new system architecture is created.

The certificate to field is only good for 1 major version of the application: 1.0.0 though 2.0.0. Minor and patch releases can be made to avoid re certification: 1.0.1 or 1.1.0

All requests behind P1's auth service have a base64 encoded JWT with general information about a user. For more info see the API's test utils file.

The API's Dockerfile accepts the argument IS_LOCAL. When IS_LOCAL is true, the API will reset the database and reseed the data. This is why the local E2E compose script starts with a fresh DB, and the staging and prod pipeline scripts persist the database.

Some cloud providers do not allow a shadow DB when Prisma pushes the schema into them. For more information see the prisma docs

1. NodeJS
2. Docker
3. Git
4. Recommended: login to hardened docker registry to run hardened images. There are minor differences between open source images and the hardened images. For example, the hardened images do not have sleep or mv

docker login registry.il2.dso.mil -u $gitlab_ci_token -p $gitlab_token_string

5. Clone the UI and API from GitLab, or UI and API from GitHub

6. Open the frontend repo

cd levels-v3-react

To compose the production app run these commands in the root of the frontend repo. If you would like to use the open source docker images, use :os at the end of these commands, and modify line 18 of ./proxy.conf to use port 80

1. Build the Production UI, DB, API, and Proxy images

docker:build:fullstack

2. Compose the services

docker:up:halfstack

While developing locally, you may like to use hot reload with React. To do this you can build the API and DB services under a Nginx proxy to develop the UI against them by running it locally. This attaches a mock user as a JWT for all requests to the API. Use :os at the end of these commands if you have not logged on to the hardened registry.

1. Build the API, DB, and Proxy services

docker:build:halfstack

2. Compose them

docker:up:halfstack

3. Install dependencies

npm i

4. Start the React development server

PORT=8080 react-scripts start

Tests are run with Jest, React Testing Library, and Cypress.

npx react-scripts test --coverage --watchAll=false

To run the E2E tests, run the following within the frontend-react repo. Use :os if you have not logged on to the hardened img registry.

1. Build the production docker images

npm run docker:build:fullstack

2. Compose the production containers

npm run docker:up:fullstack

3. Install Cypress

npm i

4. Run the E2E tests

npm run E2E

Tests are run as integrations tests inside of a Postgresql service and a node service. Between each test the database may need to be reset and reseeded. See aircraft.test for an example.

The test utils contains mocks of different user roles that can be passed to the auth header in Supertest.

Use :os at the end of these commands if you have not logged on to the hardened registry.

1. Build the API and run a container with the test script against an instance of Postgresql

npm run docker:test

See Mattermost, Jira, and Figma for the latest proposed features.

Report a bug

1. Open an issue to talk about the feature or bug fix
2. Fork the repository
3. Clone the repository
4. Implement feature with 80% line coverage
5. Submit a merge request

See licence for more information.

Teague Stockwell - matermost (@teaguezs) LinkedIn

• Platform One for deployment and devSecOps
• Brandon Swenson for helping containerize with hardened images