Integrate a citation from the devops handbook
continuous-integration/drone/push Build is passing Details

This commit is contained in:
Fred Pauchet 2021-08-24 21:35:41 +02:00
parent ba05ecf90b
commit 34058f9dcd
1 changed files with 27 additions and 0 deletions

View File

@ -19,6 +19,17 @@ Chaque déploiement de l'application se basera sur cette source, afin de minimis
image::images/diagrams/12-factors-1.png[align=center]
Comme l'explique Eran Messeri footnote:[The DevOps Handbook, Part V, Chapitre 20, Convert Local Discoveries into Global Improvements], ingénieur dans le groupe Google Developer Infrastructure, un des avantages d'utiliser un dépôt unique de sources, est qu'il permet un accès facile et rapide à la forme la plus à jour du code, sans aucun besoin de coordination.
Ce dépôt ne sert pas seulement au code source, mais également à d'autres artefacts et formes de connaissance:
* Standards de configuration (Chef recipes, Puppet manifests, ...)
* Outils de déploiement
* Standards de tests, y compris tout ce qui touche à la sécurité
* Outils de déploiement de pipeline
* Outils d'analyse et de monitoring
* Tutoriaux
*#2 - Déclarez explicitement les dépendances nécessaires au projet, et les isoler du reste du système lors de leur installation*
Chaque installation ou configuration doit toujours être faite de la même manière, et doit pouvoir être répétée quel que soit l'environnement cible.
@ -112,3 +123,19 @@ De cette manière, que nous soyons en développement sur le poste d'un développ
Evitez qu'une migration ne puisse être démarrée depuis une URL de l'application, ou qu'un envoi massif de notifications ne soit accessible pour n'importe quel utilisateur: les tâches administratives ne doivent être accessibles qu'à un administrateur.
Les applications 12facteurs favorisent les langages qui mettent un environnement REPL (pour _Read_, _Eval_, _Print_ et _Loop_) à disposition (au hasard: https://pythonprogramminglanguage.com/repl/[Python] ou https://kotlinlang.org/[Kotlin]), ce qui facilite les étapes de maintenance.
=== Design for operations through codified non-functional requirements
Pour paraphraser une section du DevOps Handbook (Part V, Chapitre 20, Convert Local Discoveries into Global Improvements (page 293-294), une application devient nettement plus maintenable dès lors que l'équipe de développement suit de près les différentes étapes de sa conception, de la demande jusqu'à son aboutissement en production.
Au fur et à mesure que le code est délibérément construit pour être maintenable, nous gagnons en rapidité, en qualité et en fiabilité de déploiement et les tâches liées aux opérations en sont facilitées.
Ces prérequis sont les suivants:
* Activation d'une télémétrie suffisante dans les applications et les environnements.
* Conservation précise des dépendances nécessaires
* Résilience des services et plantage élégant (i.e. *sans finir sur un SEGFAULT avec l'OS dans les choux et un écran bleu*)
* Compatibilité entre les différentes versions (n+1, ...)
* Gestion de l'espace de stockage associé à un environnement (pour éviter d'avoir un environnement de production qui fait 157 Tera-octets)
* Activation de la recherche dans les logs
* Traces des requêtes provenant des utilisateurs, indépendamment des services utilisés
* Centralisation de la configuration (*via* ZooKeeper, par exemple)