Make sure none of the deployment team tooling or processes depend on Gitlab.com where feasable

In order to ensure that we are still able to perform critical release/delivery functions in the cases where Gitlab.com is down, we want to try and identify and track issues related to making our tooling and processes not explicitly depend on Gitlab.com where feasible.

Some of our tooling/processes will likely always depend on Gitlab.com (as it's the source of truth for things like issues, etc.) however, in the places where we can change things to no depend on Gitlab.com, we should do so.

This will allow us to perform as much of our team function as possible even during extreme emergency situations (such as Gitlab.com being down). In fact, some of our processes (like delivering fixes) are critical to still function when Gitlab.com is down, as these processes can be the remediation to get it back up.