Building everything together versus independently releasable components

Do you have a large project that takes a long time to build? Many projects start with a few source files you can build in seconds. Over time the files multiply and start using one another. As the project grows, which most software projects inevitably do, you divide the source into modules with distinct responsibilities. To build it, you check it out of version control and run your build system. That approach has some clear advantages and some drawbacks that can turn out to matter quite a lot. I’ll outline another approach here.

Building everything together

This is the approach I just described. In simple terms, you check out the project and run the build. It has one defining feature. What you build corresponds directly to what you got from version control and any changes you made locally. If module A uses module B, any change in B also becomes visible to A.

Advantages

A code change in one place takes effect in every part of the source included in the build.

Drawbacks

Slower builds. Changing one file means building source files that have nothing to do with the change. If A uses both B and C, C has to be compiled. You keep recompiling it even if you haven’t changed the module’s classes in years. That probably means running its tests too, slowing things down further.

It’s also easy for bugs to spill across module boundaries. In our example with A, B and C, anything we change in B or C can effectively break A. If those modules belong to a part of the project we’re not responsible for, a change can have a side effect we have no idea about.

Independently releasable components

The alternative is to treat built modules or components we consider stable much as we’d treat third-party code. We have a binary and build against it. This addresses the drawbacks of building everything together.

Build speed improves. We use the existing binary for things that are stable and debugged. Versions of the same binary also help prevent bugs from spilling over. If A uses B and some eager developer starts changing B, A can keep using an older version without being affected by the changes.

The drawback is that you need infrastructure to store your own binaries and a way to manage dependencies between modules. With Apache Maven, a repository of your own artifacts, the module binaries, is enough. Maven handles artifact dependencies as part of the build. This means using specific versions for your stable, debugged artifacts instead of SNAPSHOTs.

If you use Maven and your project has several modules, some of them shared, I’d recommend making them independently releasable. That speeds up builds and tests and helps prevent defects from spilling over.