[almighty] Monorepo

[Konrad Kleine]

I agree with Thomas,

but I from an operations point of view it would be nice to know that the
docker image for core with revision X works fine.

With a monorepo (and I think this is what KB mentioned on Bluejeans) we
would need to rebuild the docker image for core every time someone makes a
ui change. This leads to a docker image for core with revision X+1. Hence,
we would need to roll out a new image even if nothing has changed.

I find that not only a waste of energy but a cause for problems. Just
consider the amount of time we spend for useless roll outs of the exact
same binary only built at different times!

Any thoughts on this?

Regards
Konrad

On Thu, Sep 22, 2016 at 11:34 AM, Pete Muir <pmuir at redhat.com> wrote:

> I agree with Thomas - this should be a practical decision, not a
> philosophical one - whatever is most convenient, right now. This is
> also one thing where I don't think consistency really matters too
> much. I'd also suggest that continually iterating on the structure is
> a good idea - what works for the team today (i.e. getting the project
> going) could be very different from 6 months time (e.g. onboarding
> contributors).
>
> On 22 September 2016 at 09:42, Thomas Mäder <tmader at redhat.com> wrote:
> > Hi folks,
> >
> > Neither mono- nor multirepo organization is inherently better or worse.
> We
> > should look at the practical issues. From a developers perspective, some
> > would be:
> >
> > Do we want different versions of the source code checked out at the same
> > time?
> > In the end, this comes down to whether different components have their
> own
> > release cycle, for example, we might develop the next version of the work
> > item storage service, but the UI still runs against a previous version of
> > the API. Our advertised approach is to always have master in production.
> > Since we have different people working on the back end and the UI, I
> don't
> > expect us to be able to make changes to the back end and front end in the
> > same pull request. However, we may have an integration branch where we
> > collect the related changes and then promote them to master atomically.
> > If we have multiple repositories, we will have to prevent breakage some
> > other way: for example with a "no breaking changes" policy (using a
> > deprecation window) or by good old coordination between contributors.
> > Tool support
> > I use VSCode to program in go (in my opinion, the code editor that sucks
> the
> > least ;-)). However, if I checkout both almighty-core and almighty-ui and
> > then open the parent folder in VSCode, I can't use the git tooling in
> VSCode
> > anymore. So for me, monorepo would work better.
> > The downside of monorepo is that you can't ever check out less than the
> > whole repo. But aside from some wasted disk space, what's the problem
> with
> > that?
> >
> >
> > Note that this is purely a git issue, if we had a svn repo, we would
> > naturally have a single repo with multiple projects (folders) in it.
> >
> > My conclusion is that I see a monorepo approach as slightly more
> convenient.
> > However, I don't think this is a game changes either way.
> >
> > /Thomas
> >
> >
> > _______________________________________________
> > almighty-public mailing list
> > almighty-public at redhat.com
> > https://www.redhat.com/mailman/listinfo/almighty-public
> >
>
> _______________________________________________
> 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/39fc5bfa/attachment.htm>