A Dev Environment Launcher is a pattern for managing the main process, and any auxiliary processes or build steps needed to get to a working interactive programming environment.

Description

In order to start working on a project, certain prerequisites need to be met, and certain processes need to be started.

Prerequisites can include

  • installing tools
  • downloading dependencies
  • configuring secrets
  • loading stub data or migrations

Processes can include

  • database servers
  • build systems (JS, CSS)
  • dependent (micro-/web-) services
  • main process for interactive development (REPL)

Ideally these different steps and requirements are fully automated. This makes onboarding new developers easy, but it also benefits existing developers, since it speeds up how quickly they can resume work on a project, lowers cognitive overhead, and limits the chance of mistakes and long winded troubleshooting.

A major reason for tension in this regard is the heterogenous nature of environments. A given team may use three different operating systems, and half a dozen different editors. This is often as a reason not to attempt automation, instead the individual steps and pieces are documented (e.g. in a README), with their possible variants, and each developer gets to puzzle the pieces together.

But this leads to more drift, where for each part or step the developer can choose to do things in their own idiosyncratic way. The result is that how things are done in practice bears little resemblance to what's documented. It is in fact common that what is documented does not actually work. The differences in environments can cause differences in behavior, and the only way to get a new developer onboarded is through oral tradition. There are also often implicit requirements, for instance to use a specific version of certain tools or dependent services (like an RDBMS), which are not enforced by the system, and thus easy to miss.

While there are great benefits to having a single, unified, standardized way of launching a complete dev environment, the result can not be too rigid. People work on different parts of a project, and so their needs will differ. They may not need to run every build process, or launch every dependent service, and forcing them to run these things anyway will cause an unnecessary hit to their productivity, and happiness.

So a certain level of local customizability is still desirable, developers may want to include additional utility libraries and tools, without committing those things to the repository, or varying configuration options at various levels.

We call the pattern that resolves these tension a "Dev Environment Launcher". A WellKnownEntrypoint that handles as much of this process as is reasonably possible. When tools are required, it either installs them, or alternatively validates that they are present, at the correct version, providing clear guidance for which steps the developer should take next to get their environment in order.

Further reading