Build a Local Dev Monorepo #137
Conversation
| - [Pants](https://www.pantsbuild.org/stable/docs/using-pants/environments#in-workspace-execution-experimental_workspace_environment) | ||
| - Etc. (this isn't by any means a definitive list) | ||
|
|
||
| ## When to Experiment |
There was a problem hiding this comment.
Could any other personas benefit from this practice? Someone who wants to be able to “see the system at work locally” (as we state above)? Someone who wants more confidence in changes? Someone who wants a more streamlined codebase?
There was a problem hiding this comment.
Just making sure this one wasn't missed. Any other personas to note?
|
|
||
| ### Create a Monorepo to Wrap the Services | ||
|
|
||
| In the parent directory, create a repo that uses a build tool that supports workspaces or monorepos (see the list above). Develop shell scripts that clone the interdependent repos into `/services` from the monorepo root, build each service, run each service, etc. |
There was a problem hiding this comment.
"see list above" edit OK?
There was a problem hiding this comment.
Maybe this can be enhanced with a link... let me add that...
There was a problem hiding this comment.
I suggest simplifying this. We don't typically use subheads in the introductions. Is "list at top of page" OK/clearer?
|
@IanDCarroll and @dcmoore -- I've completed an edit of this practice. Please see suggestions and queries. Also, is this an evolution of this practice? https://github.com/pragmint/open-practices/blob/main/practices/migrate-to-monorepo.md |
|
Let me look into those questions and clarify |
|
@ntache-81 Thanks fot the review!! |
|
@IanDCarroll and @dcmoore -- revision has been reviewed and edited. A few new comments were added, but this is looking good. Also @IanDCarroll, we’ll need to link to this as a Supporting Practice on the pages for the 3 capabilities it supports: Code Maintainability, Test Automation,, and Test Data Management. Here is a quick blurb (3-4 sentences) we could potentially use on those pages to summarize this practice (edit as you see fit, or let me know if it's good to go and I can add it to those pages). ###Build a Monorepo for Local Development |
|
|
||
| ### Add an Integration Testing Layer | ||
|
|
||
| Use this monorepo to test the seams of interaction between the services, ensuring that contracts and connections still function. This can be a harness to gain more confidence that each service previously built in isolation will still work well with the rest of the system. Snapshot testing via a framework like jest, while not ideal in the long term, can get the job done initially. Do not add unit tests here; instead, develop a script that can run through the tests on each service the monorepo houses. |
|
|
||
| ### Slow & Intangible | ||
|
|
||
| **Cleaner Service Boundaries.** Refactoring service boundaries should become easier. When everything lives in one repo, poor service boundaries can be removed with less friction. Teams can also quickly extract new services with the shared tooling, configuration, and build setup. |
There was a problem hiding this comment.
Can we clarify the phrase "poor service boundaries can be removed"? Are the boundaries actually going away? Or are the boundaries being strengthened/improved/sharpened?
—> weak service boundaries can be strengthened?
—> messy service boundaries can be cleaned?
—> unclear service boundaries can be clarified?
—> fuzzy service boundaries can be sharpened?
No description provided.