Use Auto DevOps for design.gitlab.com
We want to dogfood Auto DevOps, as dogfooding is one of our values. See also https://about.gitlab.com/handbook/engineering/infrastructure/blueprint/ci-cd/.
This project is one of the easier projects to integrate with ADO. We should learn what the pain points (increased build time & carbon footprint, for example) are and start thinking about how we may address them for projects such as this one.
These are the steps on the code and repository:
-
Updates to package.json to make it compatible: -
Add a stub yarn test
command as the test step will fail if there is no test command to run: DylanGriffith/design.gitlab.com@6f264f3b -
Remove the hardcodedMake port optional with defaultPORT
fromyarn start
as auto devops deployment expects to provide this port variable: DylanGriffith/design.gitlab.com@b3e778e2 -
Ensure yarn start
results in listening on all interfaces not just loopback as we need to access port 5000 outside of the container. This resulted in constant restarts as the health checker was killing the application: DylanGriffith/design.gitlab.com@b3a43b92
-
-
Remove .gitlab-ci.yml
so that Auto DevOps pipeline will run DylanGriffith/design.gitlab.com@452b59df
Here are the steps on the project, cluster and infrastructure:
-
Create a fork of the project in the gitlab-services
group for testing and verification -
Create a production and a staging/review K8s cluster on GKE and install tiller + ingress -
Enable Auto DevOps -
Test and verify that everything is running and publishing correctly from the K8s clusters -
Delete the forked repository, and move the real one to the new location -
Trigger the pipelines and verify that the real repository publishes to review/staging/prod -
Update DNS record to point to the new production instance -
Eventually clean up the old instance after we have confidence in the new
Edited by Devin Sylva