DEV Community

Discussion on: Simplify your monorepo with npm 7 workspaces

 
raimeyuu profile image
Damian Płaza

Yes, I suppose you're talking about docker layers and writing docker files in the way to reuse as much as possible to not trigger unnecessary operations while building the images.

I was thinking more about multiple teams (so many people) contributing to two apps and queueing builds/deploys many, many times.

Nevertheless, it might be that I'm creating imaginary issues that will never happen :-D

Thread Thread
 
limal profile image
Łukasz Wolnik

Multiple teams can create as many PRs to the monorepo as they want and each commit within the PRs will trigger a new build in a CI. It's not a problem given that builds are so quick thanks to the optimised Dockerfile.

Most of the time each team will update just their app leaving a shared UI code unchanged.

A deployment would only be a problem if the shared code had been modified. Then every app in the monorepo would have to be tested for regressions by a QA team.

But if a newly merged PR contains only code for a single app then it's perfectly safe to deploy it. For only the modified app will create a new CSS/JavaScript bundle.

I am assuming all apps would sit n a single Docker image running from a single nginx cotainer, i.e. example.com/app1 example/app2. It's be possible though to make a separate build of a Docker image for each of the apps and run them in independent containers.

A risk of regression would still be present in this scenario too as updating the shared code alters all artifacts. But that's the trade off of using a shared code/DRY principle in the first place.