Description
Today large single-repo projects are a norm. Simple in principle: "just download 1 repo and you get everything necessary to run it", a large project is often very brittle and hard to understand and work on. I will show a novel solution to testing and integrating modules that makes separate development absolutely painless, fast and efficient.
Abstract
Keeping all source together allows temporal cohesion: all the source builds together at once (assuming the continuous integration). Yet it brings the development to a screeching halt, because in order to make even the smallest change, the developer has to understand how it would affect the entire application. Working on a single large app can be compared to changing a car's engine part while the car is running!
Yet people are afraid to split a single project into smaller parts because integrating and keeping all parts working together using today's tools is a problem. I will show how to solve this problem. We can keep all parts separate, yet always guarantee the merged result to work. We can also apply modular development to open source tools and measure and predict upgrade problems. We can even design a novel continuous integration service to measure how the current module would impact the downstream dependencies.
This presentation will show several parts to the solution. While the tools I am showing target Node platform, they can be adapted to any platform or language.
- How to test new versions of the dependent projects automatically before upgrading using next-update tool. This allows a parent project to be decoupled from the individual breaking changes in 3rd party modules, yet keep up to date. I described why I wrote next-update in Painless modular development (really).
- How to predict upgrade success before upgrading by using anonymously collected upgrade data using next-update stats service. This data even allows us to measure how closely a module adheres to semantic version semantics, see Measuring semver adherence.
- How to check if the current code you are working on would break any modules dependent on before publishing new version, see dont-break.
The change from working on the single code base to separate modules leads to faster development by cutting the complexity into smaller manageable parts. The automatic testing and upgrade tools allow continuous version upgrades and efficient development work flows. The software we produce is more robust, since we can exhaustively test each part in isolation before assembling each module from smaller parts.