What process should we use to "bless" a module as "officially supported" at our company?
We got a question from a customer that I wanted to share here so others can find it: > What the steps are for our central platform team to ‘bless’ a module for general consumption? I'll share Gruntwork's recommendation below. We'd also love to hear about the processes you use at your companies! --- <ins datetime="2023-11-14T17:20:19Z"> <p><a href="https://support.gruntwork.io/hc/requests/110586">Tracked in ticket #110586</a></p> </ins>
This process varies for every company. Here are some common patterns for you to consider in your own process: 1. **Repo**. Typically, “blessed” modules must live in a specific repo: e.g., a centrally-managed `infrastructure-modules` repo. 2. **Coding conventions**. The module, and everything in that `infrastructure-modules` repo, should follow certain coding conventions: e.g., file naming, variable naming, comment style, etc. E.g., See [Gruntwork’s Terraform style guide](https://docs.gruntwork.io/guides/style/terraform-style-guide/) as a starting point. 3. **Docs**. The module must be documented. Typically, a README.md is sufficient, but for complex modules, sometimes you need more. See also the [Gruntwork Library reference](https://docs.gruntwork.io/library/reference/). 4. **Tests**. The module must have automated tests. We recommend, at a bare minimum, functional tests where, after every commit, you deploy the module to a real AWS account, validate it works as expected, and then undeploy it. You can write such tests using [Terratest](https://terratest.gruntwork.io/). 5. **Security scans**. The module must pass various security scans. You may wish to use tools such as [tfsec](https://github.com/aquasecurity/tfsec), [terrascan](https://runterrascan.io/), [OPA](https://www.openpolicyagent.org/), [tflint](https://github.com/terraform-linters/tflint), and [snyk](https://snyk.io/). 6. **Policy scans**. You may also want to enforce that the module passes various policy scans. These overlap with the security scans mentioned in the previous item—and therefore, you may use the same tools—but the policies you enforce may involve not only security requirements, but other business and legal requirements: e.g., perhaps you don’t want to allow certain AWS services to be used, so you could create a policy that scans the Terraform code for the relevant resources, and blocks merge if those are found. You might also enforce policies around compliance requirements: e.g., CIS, PCI, NIST, etc.