---
tags: v3, dev ops
---

# Broader DevOps Strategy

- Worked through the external starters
- Our initial approach with externals worked -- we'll do this combined with the changes to the plugin
- Discussed the SVG issue that Rowdy is tackling

## High-Level DevOps Discussion

- Important to be able to build things in ways that we're able to fix them ourselves
- Goal is to avoid having single points of failure -- we'd want to ideally have 2 folks who understand the build steps
- nx's `project.json` files are more complex versions of `package.json` files that allow for us to include additinal JavaScript pieces
- Start looking at how the plugins work to get a better understanding of the build steps and the underlying structures
- Don't necessarily need the knowledge up front, but this is helpful when debugging the issues
- Can look at the nx dev kit -- this provides tools that should be considered when building plugins

### Knowledge Areas

- Build system
- nx
- Plugin ecosystem
- Vite knowledge (or whatever bundler we're relying on)

### Structure

- Does it make more sense to have a few folks who have an `ops` tag instead of a single person?
- Aim for a few folks with an understanding who are able to troubleshoot -- consider pairing this with the Dev Rel role
- Ops work impacts people who consume our packages so will need to be working together
- We'll have a lot of gains from folks understanding how these processes work -- there will always be issues with any bundler we use, but having folks who are able to debug this is helpful
- How are we able to better pinpoint issues within our libraries?
- Errors aren't always surfaced well -- often a blackbox of errors
- Should we add the external packages into our build step?
- How would we trigger a build an app via GitHub Actions?
- Similar to testing the plugins:
- e2e testing on the build actions via Jest
- Potentially create an example app within the nx repo that doesn't use the nx package resolution
- Example app that references the dist
- Create examples folder within the monorepo

## Next Steps

- Concrete steps to resolve our current build issues
- Establish a "first aid team" that is able to respond to issues
- Would likely require a certain committment allocation to have 1) coverage, and 2) make sure that folks aren't overloaded
- Determine a priority tier system
- Focus on vite starter with use cases instead of supporting everything out of the box
- Be more opinionated and focus on how our toolbox can be used to support them and then expand as we have folks requesting new things (such as Next)
- Our infrastructure works (vite + Skynet for example) so we'd be able to focus on specific use cases and how our toolbox can solve them
- Research other options outside of Skynet