Hello fellow beamers!! I wish you a beautiful..? no, wonderfull..? no, charming..? oow to the heck with it. I wish you an downright exquisite and merry Christmas... Don't celebrate it? Don't worry! It seems to have turned into a consumeristic way to celebrate something that we don't really value or understand anymore anyway.. so nothing big you are missing... moreover you can be free to gift and love yourself (and/or others) any day of the year. (just an interesting bit of black humor before I begin , no offence ).
But no, really, Christmas is nice, enjoy it , then then remind yourself that the rest of the year is also nice, next enjoy that too!! .
Sooo... this post is intended to be a discussion for good and bad practices of managing large umbrella projects, by large meaning it containing many applications. Not sure if its a git or elixir discussion.
my opinions and views a story with my opinions and views, but my main concern is to hear, what the rest of you thinks about this "issue" and how do you handle it in your projects.
Hopefully we can get a conversation started to discuss all sorts of interesting things about this, maybe include how to manage these large apps in production in multyple servers and such.
Below starts my story/view on the subject, it's long, more of a fun thing, if you are opinionated you might just want to skip it and give out your opinion to start a discussion.
Suppose we are given the job of building an office application, we are told that it should take care of many different tasks, for example there should be some domain logic, a web part, a backoffice application, invoice management and generation, a crawler to track stuff on the web, connection with 3rd parties, analytics, the list just goes on... and as one might suspect there is no insurance it won't grow in the future.
Naturally we decide to go with an umbrella application and separate the concerns as needed, instantly we are faced with our first code management decision. How do we source control this system? We certainly could create one big repository and work with that, but being a bit far sighted we see that does not feel appropriate. Sure, we are small now, not many developers, and the code for the applications will be small and simple (for some time atleast), but we assume things will change, it is probable that soon developers responsible for some or one of the applications will want to manage them directly, without the main repository, maybe they'll want a separate issue tracker, and they will definitely want to have a git log dedicated to the specific problem (makes things easier to follow, does it not?).
"Submodules to the rescue!!" we exclaim, and surely, they do feel like the perfect solution, that is until we realize that we will have to create a non-negligible amount of repositories (how many did we mention like 7? try adding 3-4 more and now it's like a lot!) before we can even begin to code (well not really). And while creating them locally is pretty straight-forward, creating, linking and generally managing them online (in services like Github) is certainly going to be an undesirable chore... We pause thinking to ourselfs... maybe we should just man/woman up and go through this initial (and possibly latter aswell) pain.
Or maybe we could compromise, creating a big repository upfront and later extracting applications into submodules we deem it necessary, this seems like a pretty good compromise, however we would be losing some commit history for the respective applications.
Options with trade offs start to appear, we decide to consult the all knowing Google, so we open up a browser and write up something among the lines of "git manage large umbrella", but the most useful/insightful thing to stumble upon seems to be the following phrase:
"Shaumik is an optimist, but one who carries an umbrella."
All Most Knowing Google
At this points the rest of the team will probably just slip away.
But you are still there, you wonder for a few seconds whether, that sentence is part of an article, a comment or some kind of ad. So you click on it. Turns out its non...
It's a post though, so you read it.. And it's quite interesting, and entirely unrelated. (no!.. I won't take "but its about git!!!" as an argument)
So you say to yourself.. We got this!! We'll write down the trade offs and figure this out.
Of course by now you are alone, but that never stopped you, you take out your big-ass blog, your mechanical pencil, and that eraser you end up never using while destroying the on-pencil one.
And you start. You write, you draw, you graph, then contemplate, then write, graph and draw some more...
After some time and a lot of struggle and consideration, a fellow team-member comes to inform you that your work is no longer necessary. He continues by explaining that while you where trying to figure this out, a super intelligent AI has come to existence and all human made software was no longer necessary,
also that it's no longer the "norm" to have humans solve problems.....
Apparently you where concluding for quite some time now...
He also mentions that the project turned out to be a huge success (how could it not?! it was build with elixir, right? ), finally he notifies you that the team just ended up using a huge git repository anyway. And that, quote:
"It was a little annoying at times, but one could get things done."
So yes.. let me recite my questions. What does the rest of you think about this, and how do/did you handle the codebases of large umbrella projects?
I really hope not to hear something among the lines, "Well.. git is really bad for umbrellas, you should use [insert_your_scm_here] instead."
P.S. Sorry if this was too long. I kinda like writing. Like a lot..