Stop reading now if you don't care about the machinations, architectures, and human reality of software. This post is for software philosophers and architects.
Dries Buytaert, the founder and core committer in chief of open source Drupal (according to Built With, the second most popular content management system software among the top million web sites) posted thoughtfully on keeping his open source software always in a shippable state. He writes this after a 3-year delay in releasing Drupal 8:
"We [will] create a feature branch for each major feature and only core committers can commit to feature branches. . . . Once we believe a feature branch to be in a shippable state, and it has received sufficient testing, we merge the feature branch into the main branch. A merge like this wouldn't require detailed code review."
This is sensible and now standard practice: Develop new features as decoupled components so committers and software managers can add them to the application without breaking it. That keeps the application always in a shippable state.
But the future of software is more than decoupled components. It also requires highly decoupled runtimes. That's called a microservices architecture: decoupled components available over the Internet as decoupled services. Think of it as a software component exposed as a microservice -- a microservice component.
A microservice to place an order is decoupled from a microservice to alert you that your shoes have shipped. A microservice to display an image sized to your phone or computer is decoupled from a microservice to paint the page.