define current state of TTS Tech Stack

[afeld]

Background information

Our systems are definitely not unified in the technology/tools they use, but I think we have a few defaults in the present state. Examples that come to mind:

• Static sites: Jekyll (ideally with the uswds-jekyll theme) or Hugo on Federalist
• Back ends: cloud.gov
• Source code: A GSA-managed organization on github.com
• Search: search.gov
• Application performance/error monitoring: New Relic
• Front end components: USWDS
• User analytics: DAP
• Infrastructure/configuration as code: Terraform

Thinking of things where we "use the following unless you have a good reason not to," for procurement, compliance, and uniformity reasons. In other words, if any of the following are at all controversial within TTS, we should not include it in this first pass.

I think there's even more standardization we can/should do (e.g. "all projects should be runnable locally through Docker Compose"), but just trying to establish a baseline. Not sure if it makes sense for this to live in the Engineering Guide or Before You Ship.

See also

• Draft a Technology Radar for TTS g-devops#10
• Consolidate the "preferred" technology stack documentation into a single resource GSA-TTS/tts-tech-operations#21
• https://18f.gsa.gov/2018/03/27/four-benefits-to-using-the-full-TTS-tech-stack/

Acceptance criteria

• There's a documented list of "For X use case when building a TTS system, use Y. If you think you have a good reason not to, talk to the Tech Portfolio."

---

The assignee can add some checkboxes as a "sketch" of the steps to complete, which may evolve.

[ryanhofdotgov]

We've got a section here that is in the spirt of this: https://engineering.18f.gov/integrations/

This page and a couple of other spots need some IaC text though.

[afeld]

Nice!

• Update that list
• Note that "For software with licenses (desktop or SaaS), try and use something from the inventory before requesting something new"