[erlang-questions] how do you build your releases with/without rebar?

[Fred Hebert]

On 04/10, Garrett Smith wrote:
> 
> - A separate app per repo helps isolate it from others
> 

That works well, unless the apps are tightly related to each other, but
still warrant different supervision strategies, configurations, etc.

My apps are already well isolated based on having a bunch of processes
and whatnot. I need to isolate code and state, not necessarily
development.

One example of this is when I have 3 apps: my reporting UI, my web
front-end, and my application that manages the data model for my app.
When I change the data model for my app (I'm adding a new field!),
the change will likely need to be reflected in the reporting UI and the
web front-end, whether it is through calling convention, type specs,
etc.

These 3 apps do vastly different things, warrant their own OTP app (I
can restart, kill, upgrade the reporting UI without touching the two
others, for example), but their development cycle and the decision
making that goes behind them is still vastly similar and tightly bound
to the team that operates the project.

If there are three separate apps in 3 repos, I've successfully helped
separate them all, but I now need to have a pull request (or whatever
equivalent) for the model app, for the reporting UI, and for the web
front-end. Then if I'm using releases, I need a 4th pull request to
fetch from the new branches from the 3 other apps to send it to staging,
for example. Then I need to merge them together in the right order, do
my code reviews across repositories to see if the approach is coherent,
and so on. If there was an error? Time to start over.

Now if I'm using 3 apps within the same repo, they are still isolated in
terms of code, manipulations, updates, abstraction, but the development
process to deal with them is a lot simpler: make a fork with all the
changes done at once. Deploy that one, merge it in as one unit. The
changes are related together anyway. Rollback the entire set at once if
there's an issue.

Code isolation is good. When that code isolation is done with the cost
of making reasoning about your code harder, or with the cost of
dictating your team's workflow, you have to think about it harder. It's
possible the price is worth it in the long run, in fact it's even likely.

If you end up having to pay that price purely because the build tool you
settled for was opinionated about whether the apps in the apps/ or lib/
directory need to be checked out from other repositories or if they can
be in there already, fix that build tool of yours, because it's
clearly making decisions it should not be making.

What's more important is that a tool that supports both the apps/* and
the OTP app model can be able to also support *both* of these workflows
(using deps or not to build the release), depending on which is
appropriate for your project, team, and/or community.

Denying people a way to organize their own workflow because of your
personal opinion when the end result for the files on disk is the exact
same (someone just disagrees about how they ended up there), to me,
tells me that maybe your tool is a bit too opinionated and may need to
take a step back.

> 
> - Big apps just keep getting bigger
> 

Fine, you can migrate when the need arises. It's not hard to move OTP
apps out of apps/* and into their own repo *when you need to*.

> 
> - The extra cost could be a benefit - a "sin tax"
> 

Note that for organizations or contractors that have limited budgets and
want to host private repositories, it also has a literal dollar cost
that might be something you want to avoid.

There is a place for multiple apps in multiple repos (most of the larger
projects I work on end up being that way) -- and to then only make a
release by fetching deps in a release-building repository. This place is
not everywhere, though.

Regards,
Fred.