Test At Home

Project Status :warning: :rotating_light:

The USPS web store was successfully launched on January 18, 2022.

This back-up solution is no longer being actively developed nor used in production. It is targeted to be archived at the end of February 2022.

Overview

A web-based, mobile-responsive solution for the public to submit a pre-order request for 1 set of four COVID-19 tests to be sent directly to their home through the USPS infrastructure. This solution is intended to be a back-up for the USPS web store, if it cannot stand peak traffic.

The launch date for this solution is January 17, 2022.

For more detail, see the product scope doc

Operations

• Run Book

Development

If you're new to Rails, see the Getting Started with Rails guide for an introduction to the framework.

Local Setup

• Install Ruby 3.0.3
• Install NodeJS 16.13.1
• Install PostgreSQL: brew install postgresql
  • Add postgres to your PATH if it wasn't done automatically echo 'export PATH="/usr/local/opt/postgresql/bin:$PATH"' >> ~/.zshrc
  • Start the server brew services start postgresql
• Install Ruby dependencies: bundle install
• Install chromedriver for integration tests: brew install --cask chromedriver
  • Chromedriver must be allowed to run. You can either do that by:
  • The command line: xattr -d com.apple.quarantine $(which chromedriver) (this is the only option if you are on Big Sur)
  • Manually: clicking "allow" when you run the integration tests for the first time and a dialogue opens up
• Install JS dependencies: yarn install
• Build CSS and JS: yarn build && yarn build:css
• Create database: bundle exec rake db:create
• Run migrations: bundle exec rake db:migrate
• Run the server: ./bin/dev
• Visit the site: http://localhost:3000

For performance, we cache the root page using the Cache-Control header. By default, the form should be cached for:

env	max cache age
dev/test/ci	10 seconds
stage-small	1 minute
stage	10 minutes
prod	1 hour

Local Configuration

Environment variables can be set in development using the dotenv gem.

Consistent but sensitive credentials should be added to config/credentials.yml.env by using $ rails credentials:edit

Any changes to variables in .env that should not be checked into git should be set in .env.local.

If you wish to override a config globally for the test Rails environment you can set it in .env.test.local. However, any config that should be set on other machines should either go into .env or be explicitly set as part of the test.

Authentication

This application does not contain an authentication component. All interaction is public/guest

Inline <script> and <style> security

The system's Content-Security-Policy header prevents <script> and <style> tags from working without further configuration. Use <%= javascript_tag nonce: true %> for inline javascript.

See the CSP compliant script tag helpers ADR for more information on setting these up successfully.

Managing translation files

We use the gem i18n-tasks to manage translation files. Here are a few common tasks:

Add missing keys across locales:

$ i18n-tasks add-missing

Key sorting:

$ i18n-tasks normalize

Removing unused keys:

$ i18n-tasks unused
$ i18n-tasks remove-unused

For more information on usage and helpful rake tasks to manage translation files, see the documentation.

Testing

Running tests

• Tests: bundle exec rake spec
• Ruby linter: bundle exec rake standard
• Accessibility scan: ./bin/pa11y-scan
• Dynamic security scan: ./bin/owasp-scan
• Ruby static security scan: bundle exec rake brakeman
• Ruby dependency checks: bundle exec rake bundler:audit
• JS dependency checks: bundle exec rake yarn:audit

Run everything: bundle exec rake

CI/CD

CircleCI is in use as our CI/CD pipeline. All scans run on each PR, and security scans are also run on a daily basis.

Deployment

Each environment has dependencies on a PostgreSQL RDS instance managed by cloud.gov. See cloud.gov docs for information on RDS.

Foundry configuration

Last updated Jan 17 at 2:30p EST

Our application is deployed across four foundries, all different than the usual cloud.gov. They have been stood up for this application, anticipating high load.

Each foundry has:

• one org: gsa-tts-test-kits
• two spaces: staging and prod

In each foundatation's prod space, there are two deployed application configurations: one with Smarty Streets API enabled and one with it disabled. We are launching with Smarty Streets enabled, and plan to route traffic to the applications where it is disabled in case of a Smarty service problem.

Foundry 1: CF_FOUNDRY_API: api.fr.wb.cloud.gov

Foundry 2 CF_FOUNDRY_API: api.fr.wc.cloud.gov

Foundry 3 CF_FOUNDRY_API: api.fr.ea.cloud.gov

Foundry 4 CF_FOUNDRY_API: api.fr.eb.cloud.gov

Questions? Ask in #tts-covidtest-devops for platform, and #tts-covidtest-rails for application development and config.

Staging

First time only: create DB service with cf create-service aws-rds micro-psql test_at_home-rds-stage

cf push --strategy rolling --vars-file config/deployment/stage.yml --var rails_master_key=$(cat config/master.key)

Production

First time only: create DB service with cf create-service aws-rds <<SERVICE_PLAN_NAME>> test_at_home-rds-prod

cf push --strategy rolling --vars-file config/deployment/prod.yml --var prod_rails_master_key=$(cat config/credentials/production.key)

Configuring ENV variables in cloud.gov

All configuration that needs to be added to the deployed application's ENV should be added to the env: block in manifest.yml

Items that are both public and consistent across staging and production can be set directly there.

Otherwise, they are set as a ((variable)) within manifest.yml and the variable is defined depending on sensitivity:

Credentials and other Secrets

1. Store variables that must be secret using CircleCI Environment Variables
2. TKTK, this step needs to be updated for CircleCI deployment pipeline. Add the secret to the env: block of the deploy action as in this example
3. TKTK, this step needs to be updated for CircleCI deployment pipeline. Add the appropriate --var addition to the push_arguments line on the deploy action as in this example

Non-secrets

Configuration that changes from staging to production, but is public, should be added to config/deployment/stage.yml and config/deployment/prod.yml

Documentation

Architectural Decision Records (ADR) are stored in doc/adr To create a new ADR, first install ADR-tools if you don't already have it installed.

• brew install adr-tools

Then create the ADR:

• adr new Title Of Architectural Decision

This will create a new, numbered ADR in the doc/adr directory.

Contributing

This will continue to evolve as the project moves forward.

• Pull down the most recent main before checking out a branch
• Write your code
• If a big architectural decision was made, add an ADR
• Submit a PR
  • If you added functionality, please add tests.
  • All tests must pass!
• Ping the other engineers for a review.
• At least one approving review is required for merge.
• Rebase against main before merge to ensure your code is up-to-date!
• Merge after review.
  • Squash commits into meaningful chunks of work and ensure that your commit messages convey meaning.

Story Acceptance

TBD