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, ...
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 ...
Monorepos have been getting a lot of attention in recent years since google popularized them. If you aren't on a similar scale as google it might not work out as well for you. I've been in a startup that moved to monorepos and we quickly found that:
most tools are built with one repo leading to one artifact that gets deployed. You will have to rework all ...
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....
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
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 ...
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 ...
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....
You're basically describing GitOps. Here's how I've followed that for a containerized microservices build and deploy pipeline:
Each service repo includes it's own Dockerfile, Kubernetes manifests, and anything else needed to locally build and test the project. The base image for the Dockerfile will likely be managed from another repo but built and hosted by ...
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 ...