Commit 7ed824fb authored by Pierre Smeyers's avatar Pierre Smeyers
Browse files

doc: composability explained

parent 03f45944
Loading
Loading
Loading
Loading
+48.7 KiB
Loading image diff...
+31 −0
Original line number Diff line number Diff line
@@ -212,3 +212,34 @@ Now, here is a table that summarizes the generic templates behavior for each bra
</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).