Convert includegraphic to graphic environment

chapters/forms.tex

@@ -2,11 +2,9 @@
 
 Ou comment valider proprement des données entrantes.
 
-\begin{figure}[H]
-  \centering
-  \scalebox{1.0}{\includegraphics[max size={\textwidth}{\textheight}]{images/xkcd-327.png}}
+\begin{graphic}{images/xkcd-327.png}
     \caption{XKCD 327}
-\end{figure}
+\end{graphic}
 
 \begin{quote}
     Le form, il s'assure que l'utilisateur n'a pas encodé de conneries et que l'ensemble reste cohérent.

chapters/introduction.tex

@@ -107,8 +107,6 @@ Restez curieux, ne vous enclavez pas dans une technologie en particulie et garde
 
 \subsection*{Conventions}
 
-
-
 Les notes indiquent des anecdotes.
 
 \begin{advicebox}

chapters/maintenability.tex

@@ -74,10 +74,9 @@ Pour reprendre plus spécifiquement les différentes idées derrière cette mét
 
 Chaque déploiement de l'application, et quel que soit son environnement cible, se basera sur une source unique, afin de minimiser les différences que l'on pourrait trouver entre deux déploiements d'un même projet.
 
-\begin{figure}[H]
-  \centering
-  \scalebox{1.0}{\includegraphics[max size={\textwidth}{\textheight}]{images/diagrams/12factors-codebase-deploys.png}}
-\end{figure}
+\begin{graphic}{images/12factors/unique-codebase-deploys.png}
+  \caption{Une base de code unique pour tous les déploiements}
+\end{graphic}
 
 Git est reconnu dans l'industrie comme standard des systèmes de contrôles de versions, malgré une courbe d'apprentissage assez ardue.
 Comme dépôt, nous pourrons par exemple utiliser GitHub, Gitea ou Gitlab, suivant que vous ayez besoin d'une plateforme centralisée, propriétaire, payante ou auto-hébergée. \index{Git} \index{Github} \index{Gitlab} \index{Gitea}
@@ -134,38 +133,31 @@ Par exemple, Gitea expose la liste suivante de paramètres \footnote{\url{https:
 Nous parlons de bases de données, de services de mise en cache, d'API externes, \ldots L'application doit être capable d'effectuer des changements au niveau de ces ressources sans que son code ne soit modifié.
 Nous parlons alors de \textbf{ressources attachées}, dont la présence est nécessaire au bon fonctionnement de l'application, mais pour lesquelles le \textbf{type} n'est pas obligatoirement défini.
 
-Nous voulons 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.
+Nous voulons par exemple "une base de données" et "une mémoire cache", et pas "une base MariaDB et une instance Memcached", afin que les ressources externes puissent être attachées ou détachées en fonction de leur nécessité, et sans avoir à appliquer une modification au niveau du code applicatif.
 
-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é. une solution consiste à passer toutes ces informations (nom du serveur et type de base de données, clé d'authentification, \ldots directement \emph{via} des variables d'environnement.
-
-\begin{figure}[H]
-  \centering
-  \scalebox{1.0}{\includegraphics[max size={\textwidth}{\textheight}]{images/12factors/attached-resources.png}}
-\end{figure}
-
-Nous serons ravis de pouvoir simplement modifier une chaîne \texttt{sqlite:////tmp/my-tmp-sqlite.db} en \texttt{psql://user:pass@127.0.0.1:8458/db} lorsque ce sera nécessaire, sans avoir à recompiler ou redéployer les modifications.
+Si une base de données ne fonctionne pas correctement, par exemple suite à un 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 son code source ne soit modifié.
 Ces ressources sont donc spécifiés grâce à des variables d'environnement, et chacune d'entre elles dispose également d'un \textbf{type}, afin de profiter d'une correspondance dynamique entre un moteur d'exécution et une information de configuration.
 
+\begin{graphic}{images/12factors/attached-resources.png}
+  \caption{Gestion des ressources attachées}
+\end{graphic}
+
+Nous serons ainsi ravis de simplement pouvoir modifier la chaîne de connexion \texttt{sqlite:////tmp/my-tmp-sqlite.db} en \texttt{psql://user:pass@127.0.0.1:8458/db} lorsque ce sera nécessaire, sans avoir à recompiler ou redéployer les modifications.
+
 \section{Séparation des phases de construction}
 
 \begin{enumerate}
 \item
-  La \textbf{construction} (\emph{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 \textbf{construction} (\emph{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.
 \item
-  La \textbf{mise à disposition} (\emph{release}) associe cet ensemble à
-  une configuration prête à être exécutée,
+  La \textbf{mise à disposition} (\emph{release}) associe cet ensemble à une configuration prête à être exécutée,
 \item
-  tandis que la phase d'\textbf{exécution} (\emph{run}) démarre les
-  processus nécessaires au bon fonctionnement de l'application.
+  La phase d'\textbf{exécution} (\emph{run}) démarre les processus nécessaires au bon fonctionnement de l'application.
 \end{enumerate}
 
-\begin{figure}[H]
-  \centering
-  \scalebox{1.0}{\includegraphics[max size={\textwidth}{\textheight}]{images/12factors/release.png}}
-\end{figure}
+\begin{graphic}{images/12factors/release.png}
+  \caption{Séparation des phases de construction, mise à disposition et exécution}
+\end{graphic}
 
 Parmi les solutions possibles, nous pourrions nous pourrions nous baser
 sur les \emph{releases} de Gitea, sur un serveur d'artefacts (\href{https://fr.wikipedia.org/wiki/Capistrano_(logiciel)}{Capistrano}), voire directement au niveau de forge logicielle (Gitea, Github, Gitlab, \ldots).

parts/environment.tex

@@ -1,7 +1,7 @@
 \part{Environnement et méthodes de travail}
 
 \begin{quote}
-    Make it work, make it right, make it fast
+    \textit{Make it work, make it right, make it fast}
 
     ---  Kent Beck
 \end{quote}
@@ -43,17 +43,15 @@ Chaque mise à jour doit être réalisable de la manière la plus simple possibl
 
 Dans son plus simple élément, la mise à disposition d'une nouvelle version d'une application pourrait se résumer à ces trois étapes:
 
-\begin{figure}[H]
-  \centering
-  \scalebox{1.0}{\includegraphics[max size={\textwidth}{\textheight}]{images/diagrams/deploy-without-hassle.drawio.png}}
-\end{figure}
+\begin{graphic}{images/diagrams/deploy-without-hassle.drawio.png}
+  \caption{Déployer une nouvelle version sans encombre}
+\end{graphic}
 
 Dans une version plus automatisée, une application pourrait être mise à jour simplement en envoyant son code sur un dépôt centralisé: ce déclencheur a la responsabilité de démarrer une chaîne de vérification d'utilisabilité, de bon fonctionnement et de sécurité, pour immédiatement la mettre à disposition de nouveaux utilisateurs si chaque acteur de cette chaîne indique que tout est OK.
 
-\begin{figure}[H]
-  \centering
-  \scalebox{1.0}{\includegraphics[max size={\textwidth}{\textheight}]{images/diagrams/basic-automation.drawio.png}}
-\end{figure}
+\begin{graphic}{images/diagrams/basic-automation.drawio.png}
+  \caption{Déployer une nouvelle version sans encombre (2)}
+\end{graphic}
 
 D'autres mécanismes fonctionnent également, mais au plus les actions nécessitent d'actions humaines, voire d'intervenants humains, au plus la probabilité qu'un problème survienne est grande, même dans le cas de processus de routine.