Reevaluate deployments

[RafaelVidaurre]

There are certain things that we should reevaluate of our deployment process.

The number one priority is the huge painpoint of having to wait so long for deployments. This can be solved by simulating deployments locally in a more efficient way, and avoding having to fake-commit to trigger new builds

Answer these questions:

• [x] How can we improve caching for our docker container?
• [ ] Can we avoid having to check if something updated to be deployed? Applying a Kubernetes config that is identical to the one in the cluster will not cause a re-deploy anyways. Since we are not being able right now to avoid rebuilding packages is this necessary?
• [ ] What else are we benefiting from lerna/yarn-workspaces besides the version management and incomplete hoisting?
• [ ] Is there a better way to manager our env variables to avoid how easy it is to get them wrong?
• [ ] It seems Docker locally can timeout because of the image size or build jobs, how can we correct this?
• [ ] How can we improve our local kubernetes deployments/workflow? Can we enable live code editing/reload without rebuilding?
• [ ] Is there a better approach using an image per package?
• [ ] Evaluate GitOps

Resources

Layer caching with Yarn & Docker

COPY package.json yarn.lock ./
RUN yarn --pure-lockfile

[RafaelVidaurre]

How can we improve caching for our docker container?

The most expensive thing to cache is probably packages. Since the system uses yarn workspaces, some dependencies are hoisted in the root, while many others are spread in the packages themselves. The hoisted dependencies should be cached in their own layer.

• Is this happening or not? If not, then why? Can we correct this?
• What about splitting the project into different docker images?