Make template more opinionated

[GaryGSC]

To make this template as useful as possible for developers at OIT, there are things we'd like to add that might not be as useful for developers across campus. As an easy example, I think it's safe to say that adding Codecov integration is considered a Good Thing, but developers outside of OIT might not have licenses for it.

We've taken the stance that this template is intended to demonstrate some best practices around deploying to AWS, but that it's so far been (mostly) agnostic about what was in the container itself. The idea was that you could more-or-less just drop in a container image, even if it's in something like Go or PHP, and the rest of the stuff in this template would still be applicable. In practice, it seems that instead of dropping in an existing container image, people take what's already here and then modify it.
As a result, it'd be nice to bake in a few more opinions (e.g. jest for a test framework), but that might obscure what this repo's trying to demonstrate ("Look, here's a container. Check it out! It can talk to DynamoDB and S3!").

With that as a preamble, I'd like us to explore what opinions we should bake into this template.

What can we do to make the template more useful? Can we do it in a way that doesn't exclude developers from across campus? Can we do it in a way that developers still understand what parts of this template need to change for their specific circumstances? Should we maintain a more opinionated fork of this template for internal usage?

[yoshutch]

I say that we keep the hw templates as bare-bones as possible and put these OIT specific opinions and best practices in a fork of this repo. If developers outside OIT want some of those opinions then they can use the fork or at least see what we did in the fork as examples. If I remember correctly this template (and other hw templates) were created to show how to use our CICD and Terraform best practices.

[GaryGSC]

I think the opinions we recently added (#230/#241) help bring the template full-circle. We had an npm test step in CI, but it wasn't running any tests before.

But I think I agree. There's not much more we can add without putting more in the application code itself, but then that starts to bury the CI/CD and IaC that's here.

It's fun to see the current language breakdown:

Language	Usage in Repo
HCL	94.1%
JavaScript	5.3%
Dockerfile	0.6%

Whereas a representative repo that was generated from the template looks like:

Language	Usage in Repo
TypeScript	70.6%
HCL	27.8%
JavaScript	1.3%
Dockerfile	0.3%

[GaryGSC]

OIT specific opinions and best practices in a fork

I think I'm okay with that, as long as this repo is considered the primary source for CI/CD and IaC and that it isn't an afterthought. The reason I suggested a fork is because that makes it easy to PR from one repo to the other.

Ideally, the rest of our opinions would be constrained to application code, so we'd have very few merge conflicts.

[GaryGSC]

If there are opinions that affect GitHub Actions, we could take an approach similar to #241 where we conditionally skip the action.