[almighty] Monorepo

Travis Brown tkbrown at gmail.com
Thu Sep 22 05:15:38 UTC 2016


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.

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.

Regards, Travis


On Tue, Sep 20, 2016 at 9:41 PM, Baiju Muthukadan <bmuthuka at redhat.com>
wrote:

> 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 https://en.wikipedia.org/wiki/Codebase :
>
>   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:
> https://danluu.com/monorepo/
>
> Here is another article in the context of a microservice architecture:
> http://blog.shippable.com/our-journey-to-microservices-and-
> a-mono-repository
>
> Here is an example Monorepo: https://github.com/SeleniumHQ/selenium
> 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
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160922/e9e5d465/attachment.htm>


More information about the almighty-public mailing list