---
# System prepended metadata

title: Scope

---

# Scope
- Is this an opportunity to do more things right?
- Or do we just need to get the status quo off of Jenks?
-- I’m strongly in favor of polishing up these infra-type things. We have a very sophisticated architecture: several DBs, several services, complex dependency graphs - and DevOps investment has not risen to demands. Logging, monitoring, and automated deploys are crucial, they come first.

# Servers
- Is this the opportunity to do terraform-esque configuration?
-- I say yes: start with good fundamentals.

# Tooling
- Has anyone investigated what Bazel does for us for packaging/testing (can we leverage its knowledge of the dependency graph)?
- Has anyone investigated tooling around GitHub’s Actions? Are there useful frameworks around it?
-- I haven’t done diligence here, unfortunately.
-- I can’t vouch for Bazel personally. It may be a good fit, it may be overkill for us here. Doit is good for getting stuff up, my only fear is that we’ll wind up re-implementing bazel in doit.

# Megadocker
- Is breaking up the megadocker images in scope here?
-- Hopefully yes?

# CI
- What do we build and test?
-- Test everything on all pushes IMO.
-- Potentially on a persistent machine / integration environment - if we do lots of tests, and spin up infra for everything, our tests are going to be dominated by the cost of spinning up that infra, even when changes are micro-sized.
-- But also depends on what we have, if Bazel et al know how to parallelize tests or can take advantage of the dependency graph, that dictates what we do here.

# CD
- AJ brought up deploying everything:
-- IMO, we don’t have the HA / infra to do this, although it could change.
-- This heavily depends on parallelization, otherwise we get linearly increasing deploy times for everything, which just sucks! And we need some tooling around us to give that parallelization.
- I’m personally in favor of packaging:
-- GH Actions has watches on specific paths to publish packages
-- Some paths publish packages, but others define services (terraform!) and redeploy those
-- NPE services grab the latest built master package, whatever that is, and prod services have hardcoded package IDs
-- Don’t use with promotions or versions, just use commit IDs.
- Alternatives:
-- Don’t tackle deploys at this point, keep them in tasks.py / move them into tasks.py. Just publish new package versions to package repos and have tasks.py feed off of that.