<div dir="ltr"><div>Baiju, Thanks for the references. A monorepo would be my default for my own corporate project, but not an open source one. Google Inc. may internally have a monorepo but Kubernetes, being a Google open source project, is composed of a number of separate repos. </div><div>If the ALMighty project claims to make it easy to go from new project (and usually new repo) to production microservice but was in turn developed with a model that does not fit the goal it is enabling, then we are not eating our own dog food. I think the problems favouring a monorepo are possibly the same problems this project should help solve. </div>Regards, Travis </div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Sep 20, 2016 at 9:41 PM, Baiju Muthukadan <<a href="mailto:bmuthuka@redhat.com" target="_blank">bmuthuka@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All, Today we have organized source code across multiple Git repositories (almighty-core, almighty-ui, almighty-devdoc etc.). If we are going to create one repo per microservice, we are going to end up with so many repositories. I have noticed that some projects/organizations uses a single repository, commonly referred as Monorepo, to organize source code. BTW, Monorepo is a "monolithic" codebase but that doesn't mean the software architecture also follows a monolithic design. >From <a href="https://en.wikipedia.org/wiki/Codebase" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Codebase</a> : There are both advantages and disadvantages to a monolithic codebase, when it is compared to a distributed codebase. Most simply, a monolithic codebase simplifies integration-changes to different components or refactoring of code between components can be done easily and atomically-and allows operations across the entire codebase, but requires a larger repository and makes it easier to introduce wide-ranging technical debt. A separate codebase or a distributed codebase keeps individual repositories smaller and more manageable, enforcing at the same time separation between components, but it also requires integration between codebases (or with the main repository), and complicates changes that span multiple codebases This article by Dan Luu has more info and pointers about Monorepo: <a href="https://danluu.com/monorepo/" rel="noreferrer" target="_blank">https://danluu.com/monorepo/</a> Here is another article in the context of a microservice architecture: <a href="http://blog.shippable.com/our-journey-to-microservices-and-a-mono-repository" rel="noreferrer" target="_blank">http://blog.shippable.com/our-journey-to-microservices-and-a-mono-repository</a> Here is an example Monorepo: <a href="https://github.com/SeleniumHQ/selenium" rel="noreferrer" target="_blank">https://github.com/SeleniumHQ/selenium</a> The source code includes C++, C#, Java, Python, Ruby, JavaScript etc. Should we use Monorepo for managing source code of Almighty? I think for now, we can stick with "Manyrepo" and observe our challenges with devlopment, code quality, testing, build & deployment. And if we clearly see problems with our approach, we can switch to a Monorepo in future. But to observe problems, we need to have an understanding of what we need to look out for when using the "Manyrepo". So, I would suggest everyone to read the 2 articles given above. P.S: This is my first mail to the Almighty public mailing list :) Regards, Baiju M _______________________________________________ almighty-public mailing list <a href="mailto:almighty-public@redhat.com">almighty-public@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/almighty-public" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/almighty-public</a> </blockquote></div> </div>