Migrate Gitlab's Production Project to `ops.gitlab.net`
To further efforts to dogfood incident management product features–and to remove our dependency on the installation (GitLab.com) that we're supporting–we will export the production
project from gitlab.com and import it onto ops.gitlab.net.
A prerequisite for moving ops.gitlab.net (ops) will be to assess the production readiness of the installation. While we have no intent of publishing public issues or pages from ops.gitlab.net, the intent is for the ops installation to take over responsibility for more of our operational workflows (e.g. status page).
Additionally, adjustments will require substantial changes to the handbook instructing the Engineer On-Call to open production incidents on ops. We'll begin a campaign to inform the company of the switch, encouraging engineers and business stakeholders to verify or request access to ops. This will be necessary to view and contribute to ongoing incidents.
Lastly, we'll redirect Incident Management Automation workflows (&100 (closed)) and all other automation to use ops as the API endpoint for interaction with incident issues.
There will be a number of situations where we lose the convenience of cross referencing issues to other gitlab.com projects. We manage to handle this well enough with projects that primarily require participation from the infrastructure department alone. It could become more problematic when we need to increase visibility on issues that impact other business units.