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 hardcoded PORT from yarn start as auto devops deployment expects to provide this port variable: DylanGriffith/design.gitlab.com@b3e778e2 Make port optional with default
    • 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 Jan 13, 2021 by Devin Sylva
Assignee Loading
Time tracking Loading