If this is translated to a monorepo that means that 1 change results
in 3 pipeline triggers, while in some cases only 1 pipeline should be
I would definitely take this point into further consideration. One of the most compelling reasons for using a monorepo is that it does not create a technical separation of projects. There is only a logical ...
Git works for monorepos, but it has a few problems:
You have to check out the entire repo.
You have to fetch the entire history (generally - shallow clones are an option, but usually not useful in actual development work).
Natively, everyone has read+write access to every directory if they have it at all.
Google, probably the most famous monorepo user, ...
Monorepos are nice because it eliminates the technical constraints between multiple projects. This does however open the door to other complications within your repository (naming conventions, cross-team dependencies, merge conflict increases, etc.). I do not have any experience with CircleCI, but I will provide some input based on other CI tools I have used....
You need to narrow down your scope and deal with tooling for monorepos. There are various awesome-monorepo lists on Github (this is a recent one) to actually find out, what kind of tooling fits your use case best (what programming languages are you using?).
If you have completely isolated projects in your repository you can cobble up some bash scripting ...
The answer is: a bit of both. To satisfy the constraints of "use git" and "manage a vast codebase" Microsoft developed a new filesystem (previously they were using a variant of Perforce called SourceDepot). It's open source but I have no personal experience of using it.
Why would you want a monorepo? The most obvious reason is that you can modify an API ...
Personally I'd keep them in separate repositories, for clear customer isolation:
minimal/no risk of unwanted interference between customers
different access control for different customers is possible
different CI/CD pipelines and/or configs for different customers is possible
simpler/standard CI/CD configurations
clean per-customer repository history
What approaches are there to manage multiple package.json files that live in each feature directory
One could leave the package.json in every feature directory and let the CI read the package.json when building the app. One could define the versions of dependencies in the package.json to get control about the app. If the app works with version A.B.C of a ...
Opinions differ on what a large code base is. If you are speaking about a company with 100 engineers, I would argue that Git should still be able to handle it. It has been developed for the needs of the Linux kernel, which is not a small project on its own.
Independent of the way how you store the repository, you may run into problems. For instance, if you ...
From the perspective of build automation, I find that it is better to have multiple repositories. This allows for smaller configurations and more granular control of your build/release process. You can allow references and pull in source code to build or release (of course you can also ignore source code as well in VSTS build pipeline).
This leads to ...
Build tools like maven or gradle could benefit you greatly here. It would do exactly what you have in mind as long as you have child project definition (with a build.gradle in gradle or pom.xml in maven).
I would not recommend the script as it would mean you have to maintain and tweak it in the future. Instead, investing in build tools can give you great ...
We're using CircleCI with Go monorepo.
Here’s how it’s done:
Define a job for each service in circle config yaml.
A git push triggers CircleCI job that finds which services are part of the change.
For each service run a CircleCI job with:
Also, published as an open source: https://github....