Merge branch 'doc/composability-explained' into 'master'

</tr>

</tbody>

</table>

## Modularity & Composability

_to be continuous_ templates are built to be:

* **Modular**: each template complies to the [Single-responsibility principle](https://en.wikipedia.org/wiki/Single-responsibility_principle) while observing common architectural principles (standard behaviour per template type, generic pipeline stages, common Git workflow principles, ...)

* **Composable**: each template cooperates gracefully with others to minimize the amount of integration work. 

Let's illustrate this with an example.

Here is a pipeline of a project using multiple templates:

* Maven to build and test the Java code,

* SonarQube to analyse the code,

* Docker to containerize the application,

* Kubernetes to deploy and run the containers,

* Cypress and Postman for automated acceptance tests.

![Modular Pipeline Example](img/example-pipeline-1.png)

Composability highlights:

* the Docker build uses the artifacts produced by Maven to build the container,

* the SonarQube analysis reuses the unit tests and coverage report from Maven,

* Kubernetes deploys the Docker container built in the upstream jobs,

* Cypress and Postman automatically test the application deployed by Kubernetes in the upstream pipeline.

Other examples of composability in _to be continuous_:

* Most templates implementing publish/release feature also cooperate with the Semantic Release

  template (when used) to retrieve the next version number from Semantic Release.

* the Terraform template supports techniques to propagate generated inventory information (easy to reuse with Ansible or AWS template for instance).