Continues to describe the 12 factors.

source/part-1-workspace/12-factors.adoc

@@ -13,17 +13,22 @@ En pratique, les idées qui se trouvent derrière les points ci-dessus permettro
 
 Pour reprendre de manière très brute les différentes idées derrière cette méthode, on a: 
 
-. Une base de code suivie par un système de contrôle de versions. Chaque déploiement de l'application devra se baser sur cette source unique, ceci afin de minimiser les différences que l'on pourrait trouver entre un environnement de développement et la mise en production.
+. *Une base de code unique, suivie par un système de contrôle de versions*. Chaque déploiement de l'application se basera sur cette source, afin de minimiser les différences que l'on pourrait trouver entre deux environnements d'un même projet. On utilisera un dépôt Git - Github, Gitlab, Gitea, ... Au choix.
+
+. *Déclarez explicitement les dépendances nécessaires au projet, et les isoler du reste du système lors de leur installation*. L'idée est que chaque installation ou configuration se fasse toujours de la même manière, et puisse être répétée quel que soit l'environnement cible. Cela permet également d'éviter que l'application n'utilise une dépendance qui soit déjà installée sur un des sytèmes de développement, et qu'elle soit difficile à répercuter sur un autre environnement. Dans notre cas, cela pourra être fait au travers de https://pypi.org/project/pip/[pip - Package Installer for Python].
+
+. *Sauver la configuration directement au niveau de l'environnement*. On veut par exemple éviter d'avoir à recompiler/redéployer l'application parce que l'adresse du serveur de messagerie a été modifiée, ou parce qu'un protocole a changé en cours de route. Concrètement, toute information susceptible de modifier le comportement intrinsèque de l'application doit se trouver dans un fichier ou dans une variable d'environnement. En allant un pas plus loin, cela permettra de paramétrer facilement un container, simplement en modifiant une variable de configuration, qui spécifiera la base de données sur laquelle l'application devra se connecter.
+
+. *Traiter les ressources externes comme des ressources attachées*. On parle de bases de données, de services de mise en cache, d'API externes, ... L'application doit également être capable d'effectuer des changements au niveau de ces ressources sans que le code intrinsèque ne soit modifié. On parle alors de *ressources attachées*, dont la présence est nécessaire au bon fonctionnement de l'application, mais pour lesquelles le *type* n'est pas obligatoirement défini. On veut par exemple "une base de données" et "une mémoire cache", et pas "une base MariaDB et une instance Memcached". De cette manière, les ressources peuvent être attachées et détachées d'un déploiement à la volée. Si une base de données ne fonctionne pas correctement (problème matériel?), l'administrateur pourrait simplement restaurer un nouveau serveur à partir d'une précédente sauvegarde, et l'attacher à l'application sans que le code source ne soit modifié.
+
+. *Séparer proprement les phases de construction, de mise à disposition et d'exécution*. La *construction* (_build_) convertit un code source en un ensemble de fichiers exécutables, associé à une version et à une transaction dans le système de gestion de sources. La *mise à disposition* (_release_) associe cet ensemble à une configuration prête à être exécutée, tandis que la phase d'*exécution* (_run_) démarre les processus nécessaires au bon fonctionnement de l'application. 
+
+NOTE: Voir https://github.com/capistrano/capistrano[Capistrano] (mais je ne l'ai jamais essayé et je n'ai pas tout compris :-))
 
 NOTE: pensez à retravailler la partie ci-dessous; la version anglophone semble plus compréhensible... :-/
 
-. Déclarez explicitement et isolez les dépendances
-. Stockez la configuration dans l’environnement
+. *Les processus d'exécution ne doivent rien connaître ou conserver de l'état de l'application*. On suppose donc que toute information stockée en mémoire ou sur disque n'altérera pas le comportement futur de l'application, par exemple après un redémarrage non souhaité. Si une réinitialisation devait être nécessaire, l'application ne devra pas compter sur la présence d'une information système.
 
-NOTE: quelle configuration ?
-
-. Traitez les services externes comme des ressources attachées (*?*)
-. Séparez strictement les étapes d’assemblage et d’exécution (*?*)
 . Exécutez l’application comme un ou plusieurs processus sans état (*?*)
 . Exportez les services via des associations de ports (*?*)
 . Grossissez à l’aide du modèle de processus (*?*)