L'attuale organizzazione del codice e della configurazione che descrivi è strutturata dalle soluzioni tecniche coinvolte. Questo è un cattivo design che aggiungerà molto overhead nelle nostre attività di manutenzione e aggiungerà anche molte trappole sulla nostra strada. Invece, tale organizzazione dovrebbe essere strutturata attorno ai manufatti che stiamo implementando.
La ragione di ciò è che vogliamo considerare i manufatti ( ad esempio un'immagine docker o un pacchetto software) come gli oggetti dei seguenti verbi:
considerare una serie minima di attività automatizzate che vogliamo svolgere. Se vogliamo cambiare qualcosa su come viene implementato il verbo di prova, è facile visitare la cartella corrispondente a quel manufatto nel repository appropriato e quindi scoprire gli elementi di automazione specifici di jenkins che devono essere aggiornati. Invece, se le ricette di automazione sono strutturate attorno a soluzioni tecniche, allora dobbiamo capire all'improvviso che jenkins è coinvolto nelle procedure di test e trovare lì gli elementi di automazione relativi agli artefatti. In situazioni complesse, l'organizzazione attorno alle soluzioni tecniche rende gli aggiornamenti molto difficili, perché dobbiamo conoscere a priori tutte le soluzioni tecniche coinvolte in alcuni servizi per aggiornarle di conseguenza.
Ad esempio, un repository contenente il codice per un sito Web e un micro-servizio "a" potrebbe avere le seguenti sottodirectory dedicate alle operazioni:
./ops/website
./ops/micro-service-a
ciascuno con tre script chiamato build, teste deploy. Ora che l'organizzazione degli articoli di automazione è stata in qualche modo chiarita, rivolgiamo la nostra attenzione alla configurazione.
Le principali condizioni e requisiti sull'organizzazione della configurazione sono impostate dal deployverbo quando applicate su un artefatto simile a un servizio. Il deployverbo dovrebbe avere i seguenti parametri:
- la versione del manufatto da distribuire,
- il target di distribuzione del manufatto, che descrive l'ambiente concreto in cui verrà eseguito il manufatto distribuito ( ad esempio un cluster e gli endpoint con cui dovrebbe parlare)
- le credenziali che dovrebbe utilizzare per connettersi ad altri endpoint ( ad es. database)
- la configurazione di runtime di (come la durata delle voci della cache, ecc.)
Dal punto di vista operativo, questa suddivisione della parametrizzazione corrisponde ai naturali gradi di libertà del problema di distribuzione - a parte le credenziali che potrebbero essere raggruppate con la configurazione di runtime, ma è meglio separarle per evitare di diffonderle con noncuranza.