Respecting the codebase factor (from 12-factor app manifesto) for a Gradle/Spring app deployed on Cloudfoundry or Heroku

Question

My question relates to the first factor of 12 factor apps manifesto: the codebase. (see http://12factor.net/codebase).

TL;DR:

this factor states there's a one to one relationship between codebases and deploys, so in this case, you're not supposed to use the same codebase (repository) for both applications

My requirement: I have an website Spring application and a batch Spring application both sharing a common code i.e. the domain model (JPA entity classes). I need to be able to share this common code. And both applications need to use the same version of the common code at any one time.

My current setup: I have currently three "top-level" repositories on github:

• Domain model (JPA entity classes) repo
• Website application repo
  • Domain model directory/gradle project (included with git subtree pull/push)
• Batch application repo
  • Domain model directory/gradle project (included with git subtree pull/push)

Please also note that the Domain model repo lives separately (as noted above) but is also nested within both the website and the batch application repos. I use a git subtree pull/push in order to include this Domain model repo as a directory and a gradle project within the other two repos. The reason for this is that Heroku builds the code itself from the repos.

All this is very tedious and error-prone.

Can someone please advise a better solution?

Bunting

I don't really understand your question. Can you break it down and be clearer? – Gompers

Answer 1

I would publish the common code to a private Maven repo on Bintray and then add that private repo to the other consumer apps and specify the common module as a dependency. This doesn't guarantee that both will depend on the same version but that could be easily managed through external processes using tools like the Maven Versions Plugin. But you also might want to add a more flexible serialization system to loosely couple the domain models of the two apps.

Masterpiece

Answer 2

I would bundle the domain models in a package (not sure what java / gradle speak for such bundles is, in ruby it would be a gem) and install it on production as a dependency. Otherwise a git submodule is also an option

Fukien

Hi. Can you please explain how that comply with the 12-factor application manifesto. Also please state how the requirement in bold above is met i.e. both applications need to use the same version of the common code at any one time. – Bunting

A bundled dependency will effectively not be part of the app codebase. Updates to the common libraries would be managed by dependency updates instead of app codebase updates. As far as I know this is one of the main reason dependencies were created, even though they are normally used to import and use 3rd party code. – Fukien