CodeForPhilly/balancer-main

Developers have a shared, easily deployed docker environment for balancer-backend

Closed this issue · 0 comments

New developers (and devs in a new enviornment) can quickly deploy a local instance of the project.

Purpose: Unify our environments for less debugging and more development!

Description

Given our different hardware and environments, a layer of abstraction will be useful for co-development. This will also yield the following long term benefits:

  • Environment mirrors what will be released into production
  • Setup can be automated for unfamiliar parts of the stack (e.g., a backend dev shouldn't need to know the intricacies of node to interact with the frontend).

Functionality: Will not replace any previous environment, but will be a first-try at a standard going-forward.

Description

The larger goal is to create a unified (docker based) standard for how we add new architectural components. Ideally, one can pull, rebuild their containers, re-deploy, and keep working.

Affects: Nothing currently, but has large future implications.

Pros

  • I've already put a good amount of work into Python-Docker, and have abstracted much of the work of deploying stacks similar to what we're aiming for.
  • Docker is pretty foundational to dev-ops, and this is a chance for newbies and vets to get more familiar with it.
  • Anyone new to the project can quickly get started, and without conflicting with concurrent environments they use for other projects.

Cons

  • Containerization is still more resource intensive than not using containers.
  • Not many people use Python-Docker, and though it's documented, I'm sure it's opinionated. I'm certainly open to other people improving it!

Alternatives:

VMs

We could use VMs, but I think it'll consume more resources without large benefit. It is easy enough now to use a container for web-hosting, and to then access that container from the host.

Configuration scripts

We could require a discrete number of configurations and take responsibility for scripting environment installation, but I don't think there are any clear advantages to doing that (though we may want to script Docker installation).

Additional context

None for now