[almighty] Monorepo

[Suraj Deshmukh]

Hi,

On Wed, Sep 21, 2016 at 8:11 AM, 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

With respect to our discussion above found a lightening talk(~5min)
about "Monolithic repositories vs. Many repositories" [1].

Desc:

Deciding to use a monolithic repository or many repositories for your
next project is not easy. Why not using both strategies? That’s
possible with split.sh, an open source tool that automates the
splitting of a monolithic Git repository into many standalone
repositories.

[1] http://www.thedotpost.com/2016/05/fabien-potencier-monolithic-repositories-vs-many-repositories

-- 
- Suraj Deshmukh (surajd)

https://deshmukhsuraj.wordpress.com
https://twitter.com/surajd_