At a glance

In order to deploy reliably as a developer I want automation.

Acceptance Criteria

We use DRY behavior-driven development wherever possible.

Scenario: cutting a release

Our goal is to release early and often. Ultimately, our goal is:

Commits to main push to dev, gated by tests
Daily, we automate a push to staging, gated by tests
Manually, we push to production

Currently, there is only a sandbox environment. We will begin by treating it as dev: every push to main will deploy to the sandbox.

### then... 
- [ ] [a thing happens]

Shepherd

UX shepherd:
Design shepherd:
Engineering shepherd:

Background

Security Considerations

Required per CM-4.

Process checklist

## Getting things done - [ ] Has a clear story statement - [ ] Can reasonably be done in a few days (otherwise, split this up!) - [ ] Shepherds have been identified - [ ] UX youexes all the things - [ ] Design designs all the things - [ ] Engineering engineers all the things ### If there's UI... - [ ] Screen reader - Listen to the experience with a screen reader extension, ensure the information presented in order - [ ] Keyboard navigation - Run through acceptance criteria with keyboard tabs, ensure it works. - [ ] Text scaling - Adjust viewport to 1280 pixels wide and zoom to 200%, ensure everything renders as expected. Document 400% zoom issues with USWDS if appropriate. - [ ] Meets acceptance criteria - [ ] Meets [QASP conditions](https://derisking-guide.18f.gov/qasp/) - [ ] Presented in a review - [ ] Includes screenshots or references to artifacts - [ ] Tagged with the sprint where it was finished - [ ] Archived

GSA-TTS / jemison