With a monorepo with this kind of structure
.
├── api
│ └── index.js
└── web
├── index.html
├── main.css
└── main.js
Assuming you changed the web/index.html and web/main.css files, in CI, how would you deploy only the web directory?
Vice versa if you only changed api/index.js only deploy the api, not the frontend.
Top comments (5)
I like to deploy projects by cloning the git repo in the root directory of the web server. Then to do an incremental update it's just a matter of doing a git pull to pull down the latest changes.
Here's a GitHub action I wrote that does that whenever a change to the master branch is pushed to the origin github.com/kingkool68/testing-gith...
Yeah, so assume the web and api were two separate standalone services, deployed to different servers, I guess that wouldn’t work?
You could use a Continuous Integration pipeline that automatically commits the changes to two different repos in a folder structure and deploy them to production as two separate repos while maintaining and authoring in one repo.
Or deploy the monorepo to production in a non-public folder and automatically move the two directories to different locations in the servers web root.
With a bit of scripting you could make this work.
By looking at the commits since the last build and stubbing out the stages/jobs for things that didn't change.
Most CI systems either already give you a list of what commits the build is for, or they provide some easy way to find out, and even if they don't, you can save the state of the previous build somewhere to compare against.
Once you have that list of commits, you can easily get a file list (for example:
git diff --name-only ${COMMIT1}..${COMMIT2}from the root of the repo) and match on that file list to decide whether to actually run a stage/job or not.See this script for an example of doing this on Travis, with appropriate special handling for PR's. I've been working on a post about this actually, but just haven't finished it yet.
I did think about that, I think Lerna is better suited to keeping multiple npm packages in sync rather than applications, but potentially could be used