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).
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:
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
Cons
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