...

• How does a multi-service dev env know which local git repositories (as filesystem directories) correspond to which dependencies?

  • Tilt has you decide for yourself, but suggests that all repositories be checked out under the same parent directory, as we do with devstack.

  • Coder probably manages all of this for you (since I don’t think it even lets you check out the code locally – all editing seems to be done in the workspace)

• We should check into whether any of these make it easier/harder to use pip install -e when working with libraries in an IDA.

• Things that would improve devstack now, and that would still help us in any new system:

  • Removing Ansible from our image-building, because our approach to Ansible is currently complicated by our re-use strategy, and because our Ansible reads from a config repo as it runs—whereas base Docker images would be config-free and would work across dev, stage, and prod.

  • Better auto-reloading (migrations, static assets, requirements)

• Tools not assessed: Ambassador Telepresence, Garden, Skaffold

Features and Facets

• It was hard to evaluate the options for cloud dev env management without knowing exactly what we want to replace from our dev environment (or add to it)

• We created a feature breakdown of Open edX dev environments at https://docs.google.com/spreadsheets/d/1XAipznjIcTaE2H454M74No2Ro_9VftbolfV4YVv-B9I/edit#gid=0 , and wrote https://github.com/edx/edx-arch-experiments/issues/203 for refining it

• Once we had a list of features, we started finding categories of them; essentially different facets of a complete development environment:

  • Standardization - Things we can get just by standardizing across our repos

  • Selection - Things needed to specify a desired subset of services and make sure common development tasks operate on exactly that subset

  • Orchestration - Things that are closely tied to the container orchestration system (typically docker-compose or Kubernetes)

  • Deployment - Things that are closely tied to how/where an environment is deployed: Docker Desktop (local), EC2 (cloud), EKS, etc.

  • Integration - Things that serve as glue for features in the other categories: do X for every repo in a particular set, do X for every service currently running, etc.

• Some of the tools are Kubernetes-only

• Spitballing:

  • Selection - go with Tutor plugins

  • Orchestration - Kubernetes preferred, but support docker-compose if possible

  • Deployment - find the best thing to smooth the Kubernetes learning curve, make it an option for Tutor

  • Integration - Tutor CLI?

• For comparison:

  • Tutor with problematic areas replaced/supplemented with another tool

  • Go with another tool from the ground up

    • Possibilities

      • Devspace