Skip to main content
U.S. flag

An official website of the United States government

Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.


Secure .gov websites use HTTPS
A lock ( ) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

Our approach

Project teams may vary, but across TTS engineering we aim for consistency around deployments, git etiquette, and similar workflow conventions.

Continuous Integration & Deployment


  • Ensure that your project is running automated tests in CI. Successful test completion should be a requirement for deployment.
  • Generally, CI should perform deployments. This ensures the deployments are repeatable and don’t rely on individual development environments. See our documentation on continuous deployment for details on how to set this up.
  • Deployments should be zero-downtime, achievable through tools like Cloud Foundry’s rolling deployment process.
  • In addition to deployments after code change, we generally need to (automatically) re-deploy daily to ensure the running containers haven’t been tampered with (an ATO compliance requirement). See CircleCI’s “schedule” docs for details.

Git & GitHub

Git is our version control system of choice and GitHub is our current repository platform, but how to use these tools can be spelled out in a bit more detail. Note that we are looking to consolidate this with our existing documentation on code review and example workflows.


  • Install our version of git-seekret as a pre-commit hook. This will check for many common types of API tokens and other sensitive information from making its way into version control.
  • Enable two-factor authentication for your GitHub account. This is required for all TTS employees.
  • Default to public for new repositories. See our guidelines about open source for more detail.
  • As part of the ATO process, we require any branches which trigger automated deployment be protected by passing CI and peer review.


  • Generally we prefer branches over forks to ease internal collaboration. If your project has many outside contributors, consider forks instead.
  • When in doubt, use feature branches and gitflow as your branch naming scheme.
  • Keep your repository clean; delete merged branches and avoid committing files specific to your dev environment (e.g. .DS_Store).
  • Follow this guidance about good commit messages.
  • Consider signing commits with a GPG key

Code style

  • Use an opinionated automated code formatter whenever possible. This saves teams from wasting time arguing about code style, and makes it easy to comply. Specific suggestions in the pages for each language.
Looking for U.S. government information and services?