While any self-respecting Agile (eXtreme Programming or similar, preferably) team will do “thin vertical slices” of functionality with a top-down approach for development, sometimes stacks can become unwieldy.

Mountebank is a few years old now, and quite a solid tool, despite being pitched at hipsters. It allows you to mock out depended-on services where TCP/IP separates you from that service. There is a neat way to use such tools to allow front end and backend teams to work at a high pace without being tied to a full-stack build.

Technology Compatibility Kits (TCKs)

This isn’t an invention of anything, just a description of something that’s been done occasionally for a number of years.

You should have two repos - one for frontend stuff, and one for backend. If you’re doing the Google or Facebook style mega-trunk, then that would be two directories in the same repo/trunk with separate builds. The front-end team can program at full speed without always bringing up the backend. Similarly the backend team can work at full speed without ever kicking off the frontend team’s build. Note, this is detach rather than decouple.

Mountebank as a mocked/stubbed backend facilitates the frontend team’s full speed. Integration tests, that are part of the frontend team’s repo (above the red line), are part of the backend team’s toolchain to prove that what they are making fits the expectations of the front end team. Running those integration tests against the mountebank mocks is a proof that everyone is on the same track - and that is the TCK.

So, I show four permutations above, because there are four pieces of news that a CI build loop should publish. That could be four CI configurations, but it could as easily be one larger one, with a pipeline. Granted that is not so easy when there’s two repos involved in the checkout. WebDriver may play too: comprehensive and really fast for the frontend with mountebank, and much much shorter or “happy path” for the full stack CI build loop.

Really this fits development that uses JavaScript micro-frameworks more than it does “web 1.0” technologies. But it is still possible there, if there’s a set of service calls from the Rails/Django/JSP/ASP tier to layer below it:

There are small complexities with Mountebank too - you have to bring up a server process for Mountebank itself, before running the test suite, and then tear that down at the end of the build. Some googling will help you overcome that.

Also, don’t forget the gold standard of Agile development, though: thin vertical slices all the way through the stack, and small stories.