| Raft-Tech(raft-tdp-main) | HHS(main) | |
|---|---|---|
| Build |  |
 |
| Security | Dependabot-Dev | Advisories-HHS |
| Frontend Coverage |  |
 |
| Backend Coverage |  |
 |
Due to limitations imposed by Github and occasional slow server response times, some badges may require a page refresh to load.
Welcome to the home of the TANF Data Portal (TDP), a new software development project from the Office of Family Assistance (OFA), an office within the Administration for Children Families (ACF).
- Product planning page includes latest information on our product mission, goals, roadmap, and backlog.
Both the frontend (http://localhost:3000) and the backend (http://localhost:8080) applications run within Docker. Instructions for running these containers are below:
$ cd tdrs-frontend && docker-compose -f docker-compose.yml -f docker-compose.local.yml up -d
$ cd tdrs-backend && docker-compose -f docker-compose.yml -f docker-compose.local.yml up -d
After the above commands there will be a total of 5 running containers
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c803336c1f61 tdp "bash -c 'python wai…" 3 seconds ago Up 3 seconds 0.0.0.0:8080->8080/tcp tdrs-backend_web_1
20912a347e00 postgres:11.6 "docker-entrypoint.s…" 4 seconds ago Up 3 seconds 5432/tcp tdrs-backend_postgres_1
9c3e6c2a88b0 owasp/zap2docker-weekly "sleep 3600" 4 seconds ago Up 3 seconds (health: starting) tdrs-backend_zaproxy_1
7fa018dc68d1 owasp/zap2docker-stable "sleep 3600" 41 seconds ago Up 40 seconds (unhealthy) 0.0.0.0:8090->8090/tcp zap-scan
63f6da197629 tdrs-frontend_tdp-frontend "/docker-entrypoint.…" 41 seconds ago Up 40 seconds 0.0.0.0:3000->80/tcp tdp-ui
Below is a GIF of both the frontend and backend running locally
Detailed instructions for running unit and end-to-end integration testing on frontend and backend are available below
TDP Uses Infrastructure as Code (IaC) and DevSecOps automation
Login.gov TDP requires strong multi-factor authentication for the states, tribes, and territories and Personal Identity Verification (PIV) authentication for OFA staff. Login.gov is being used to meet both of these requirements.
Cloud.gov is being used as the cloud environment. This platform-as-a-service (PaaS) removes almost all of the infrastructure monitoring and maintenance from the system, is already procured for OFA, and has a FedRAMP Joint Authorization Board Provisional Authority to Operate (JAB P-ATO) on file.
On each git push and merge, a comprehensive list of automated checks are run: Unit tests (Jest, Cypress), Integration tests (Cypress), Linting tests (ESLint and Black), Accessibility tests (Pa11y), and Security Scanning (OWASP ZAP). The configurations for CI are kept in .circleci/config.yml.
The application is continuously deployed to the dev, vendor staging, gov staging or prod environments based on the git branch the code is merged in. The configuration for different branches is maintained in .circleci/config.yml.
See Architecture Decision Record 008 - Deployment Flow - for more.
The application is deployed to the following environments:
| Environment | URL | Git Branch |
|---|---|---|
| Development | https://tdp-frontend.app.cloud.gov/ | raft-review in Raft fork |
| Vendor staging | https://tdp-frontend-vendor-staging.app.cloud.gov/ | raft-tdp-main in Raft fork |
| Gov staging | TBD | TBD |
| Production | TBD | TBD |
The application can be manually deployed from any open Pull Request by assigning the label Deploy with CircleCI.
This works using a GitHub Action that runs every time a label is assigned to a PR. If the assigned label matches the string defined above a cURL request is made to CircleCI to initiate a deploy job for the given PR's branch.
Which deployment environment within Cloud.gov the deploy job targets depends on the branch name as follows:
- Branch name
staging=> deploys to Gov Staging **(once it exists) - Branch name
raft-tdp-main=> deploys to Vendor Staging - All other branches deploy to the Development environment
Note that the Production environment is omitted above, since main is a protected branch commits can't be made directly
to it so there is no path to be able to deploy straight to Production from labels on PRs.
- NOTE: This only applies to deployments targeting the tanf-dev space.
In the case where a developer needs to make changes to the actual scripts used by Circle CI for deployments (found in the /scripts folder at the root of this project) these scripts can also be run locally provided that the developer has an active account in Cloud.gov and has been granted the "Developer" role.
You must first install the Cloud Foundry CLI tool
There are several environment variables that may be needed for the backend depending on the deployment strategy used which must be kept secret and as such should not be stored anywhere outside of Cloud.gov / Circle CI. In order to retrieve these values to supply to the deploy script you can use the following commands:
cf api https://api.fr.cloud.gov
cf login --sso
cf env tdp-backend
Before running your target script export any wanted variables from the output of that last command to your current shell by running:
export MY_VAR=[VALUE]
To prevent interrupting ongoing testing against a deployment environment it is important to always communicate with the Team before assigning this label to a new PR. This can be done as a general announcement in either Mattermost (vendor environments) or MSFT Teams (gov staging).
Currently the GitHub action defined in the workflow in this repo is only enabled on the raft-tech fork.
In order to enable the action take the following steps:
- Create a CircleCI API Token in Project Settings
- NOTE: You can't see this again so make sure to save it in a secure place before proceeding.
- Save the token from above as a Repository Secret in GitHub
- NOTE: The secret must be named
CIRCLE_CI_API_TOKENexactly or the workflow won't run
- NOTE: The secret must be named
- Ensure that actions are enabled for the repository
