The current organisation of the code and configuration you describe is structured by the technical solutions involved. This is a bad design that will add a lot of overhead in our maintenance activities and will add a lot of traps in our way as well. Instead, that organisation should be structured around the artefacts we are deploying.
The reason for this is that we want to consider artefacts (e.g. a docker image or a software package) as the objects of the following verbs:
to consider a minimal set of automated tasks we want to perform. If we want to change something about how the test verb is implemented, it is easy to visit the folder corresponding to that artefact in the appropriate repository and then discover the jenkins-specific automation items that needs to be updated. Instead, if the automation recipes are structured around technical solutions, then we need to figure out of the blue that jenkins is involved in the test procedures and find there the artefact related automation items. In complex situations, the organisation around technical solutions makes updates very hard, because we have to know a priori all the technical solutions involved in some service to update them accordingly.
For instance a repository containing the code for a website and a micro-service “a” could have the following sub-directories dedicated to operations:
each having three scripts called
deploy. Now that the organisation of automation items has somehow been clarified, let's turn our attention to configuration.
The main conditions and requirements about the configuration organisation are set by the
deploy verb when applied on a service-like artefact. The
deploy verb should have the following parameters:
- the version of the artefact to deploy,
- the deployment target of the artefact, which describes the concrete environment where the deployed artefact will run (e.g. a cluster and endpoints it should talk to)
- the credentials it should use to connect to other endpoints (e.g. databases)
- the runtime configuration of (like how long cache entries should live, etc.)
From the operational perspective, this breakdown of the parametrisation matches the natural degrees of freedom of the deployment problem – aside from the credentials that could be bundled with the runtime configuration, but it is better to separate them to avoid spreading them carelessly.