# How many types of quality gates can you think of?
Some of the folks involved in `#sig-interoperability` (which could be you!) [had a discussion](https://github.com/cdfoundation/sig-interoperability/discussions/83) about the different types of quality gates that folks could use when validating code destined for production. A quality gate, for those unfamiliar, is a part of the validate/deploy process that is intended to assert that the code that passes through it is safer than code that doesn't. One common one that we use is "do the tests pass?" Before we run the tests, the change is risky. After we run our tests.. it's way less risky. The general idea is that if you have a bunch of quality gates you can "automate confidence" (to steal a phrase I first heard by [Michael Stahnke](https://www.linkedin.com/in/mstahnke/) at [cdCon](https://events.linuxfoundation.org/cdcon/)).

One great point by [Ann Marie Fred](https://www.linkedin.com/in/amfred/) was that when the number of quality gates increases, we begin to need a capability to support speculative execution (trying multiple pipeline steps even though their result may not be relevant because an earlier step failed). This is particularly important so developers can get the full list of issues they need to fix without submitting build after build.

So here they are:

## Commit
1. pre-commit hooks to validate commit messages

## Merge
1. Some folks have robots which do the merge for you
1. Contributor License Agreement checks

## Build
1. SBOM generation
1. Ensure there are no CVEs in the transitive dependencies
1. Validate unit tests pass
1. Run contract tests
1. Gather other quality metrics (sonar, coverage, etc)
1. License validation
1. Validate application configuration is within range (e.g. not requesting too many replicas)
1. Infrastructure policy validation (not exposing endpoints publicly)
1. Validate credentials aren't in the code
1. Has had code review
1. Validate correct cryptographic signatures are in place (e.g. on commits and resulting binaries)

## First deploy
1. Budget analysis (ensure the change won't trigger cloud cost overruns)
1. Deployment windows (don't push during certain times of day)
1. run end-to-end tests
1. performance benchmarking

## Prod deploy
1. Roll out via canary (e.g. small percentage of traffic at first, and ramp as we gain confidence)
1. Monitor key health metrics

## Release
1. Similar to First Deploy, but used for libraries who don't deploy services.

If this sort of thing is as exciting to you as it is for us, we'd love to see you at the next sig-interoperability meetings. They are held on the first and third Thursdays at 15:00UTC. For more information, [check us out on GitHub](https://github.com/cdfoundation/sig-interoperability).

Thank you to the following folks who contributed to this discussion:
- [Ann Marie Fred](https://www.linkedin.com/in/amfred/)
- [Muktesh Mishra](https://linkedin.com/in/mukteshkrmishra)
- [Anders Eknert](https://www.eknert.com/)
- [Fatih Degirmenci](https://cicd.tech/about/)
- [Thanh Ha](https://www.zxiiro.ca/)