Resize images to fit page layout
continuous-integration/drone/push Build is passing Details

This commit is contained in:
Fred Pauchet 2022-06-17 21:31:50 +02:00
parent 862d2d01f6
commit 0578564c37
3 changed files with 124 additions and 71 deletions

View File

@ -1,96 +1,109 @@
\chapter{Fiabilité, évolutivité et maintenabilité}
\begin{quote}
The primary cost of maintenance is in spelunking and risk\cite[139]{clean_architecture}
--- Robert C. Martin
The primary cost of maintenance is in spelunking and risk\cite[p. 139]{clean_architecture}
\end{quote}
Que l'utilisateur soit humain, bot automatique ou client Web, la finalité d'un développement est de fournir des applications résilientes, pouvant être mises à l'échelle et maintenables \cite[p. 6]{data_design} :
Que l'utilisateur soit humain, bot automatique ou client Web, la finalité d'un développement est de fournir des applications résilientes, pouvant être mises à l'échelle et maintenables \cite[p. 6]{data_intensive} :
\begin{itemize}
\begin{enumerate}
\item
La résilience consiste à ce que l'application continue à fonctionner \textit{correctement} - c'est-à-dire à ce qu'elle fournisse un service correct au niveau de performance désiré, même quand les choses passent mal.
Cela signifie que ces systèmes ont la capacité:
\textbf{La résilience} consiste à ce que l'application continue à fonctionner \textit{correctement}, c'est-à-dire à ce qu'elle fournisse un service correct au niveau de performance désiré, même quand les choses se passent mal.
Ceci signifie qu'un système a la capacité:
\begin{enumerate}
\item
D'anticiper certains types d'erreurs (ou en tout cas, de les gérer de manière propre), par exemple en proposition une solution de repli (\textit{fallback}) \footnote{Lors d'un incident AWS, Netlix proposait des recommandations statiques et ne se basait plus sur des recommandations personnalisées. Ceci leur a permis de tenir six heures avant de décréter être impacté. \cite{devops_handbook}}
D'anticiper certains types d'erreurs (ou en tout cas, de les gérer de manière propre), par exemple en proposant une solution de repli (\textit{fallback}) \footnote{Lors d'un incident AWS, Netlix proposait des recommandations statiques et ne se basait plus sur des recommandations personnalisées. Ceci leur a permis de tenir six heures avant de décréter être impacté. \cite{devops_handbook}}
\item
De se rendre rapidement indisponibles les composants qui posent problème, de manière à ce que ceux-ci n'entraînent pas tout le système avec eux (\textit{fail fast})
\item
De retirer certaines fonctionnalités non-critiques lorsqu'elles répondent plus lentement ou lorsqu'elles présentent un impact sur le reste de l'application (\textit{feature removal}).
\end{enumerate}
\item
La mise à échelle consiste à autoriser le système à \textit{grandir} - soit par le trafic pouvant être pris en charge, soit par son volume de données, soit par sa complexité.
\textbf{La mise à échelle} consiste à autoriser le système à \textit{grandir} - soit par le trafic pouvant être pris en charge, soit par son volume de données, soit par sa complexité.
\item
Au fil du temps, il est probable que plusieurs personnes se succèdent à travailler sur l'évolution d'une application, qu'ils travaillent sur sa conception ou sur son exploitation.
La maintenabilité consiste à faire en sorte que toute intervention puisse être réalisée de manière productive.
\end{itemize}
\textbf{La maintenabilité} consiste à faire en sorte que toute intervention puisse être réalisée de manière productive: au fil du temps, il est probable que plusieurs personnes se succèdent à travailler sur l'évolution d'une application, qu'ils travaillent sur sa conception ou sur son exploitation.
\end{enumerate}
Pour la méthode de travail et de développement, nous allons nous baser sur les \href{https://12factor.net/fr/}{The Twelve-factor App} - ou plus simplement les \textbf{12 facteurs}.
Suivre ces concepts permet de:
Une manière de développer de telles applications consiste à suivre la méthodologie des \textbf{12 facteurs} \footnote{\href{https://12factor.net/fr/}{The Twelve-factor App}}
Il s'agit d'une méthodologie consistant à suivre douze principes, qui permettent de:
\begin{enumerate}
\item
\textbf{Faciliter la mise en place de phases d'automatisation}; plus
concrètement, de faciliter les mises à jour applicatives, simplifier
la gestion de l'hôte qui héberge l'application ou les services,
diminuer la divergence entre les différents environnements d'exécution et offrir la possibilité d'intégrer le
projet dans un processus
d'\href{https://en.wikipedia.org/wiki/Continuous_integration}{intégration
continue} ou
\href{https://en.wikipedia.org/wiki/Continuous_deployment}{déploiement
continu}
\textbf{Faciliter la mise en place de phases d'automatisation}; plus concrètement, de faciliter les mises à jour applicatives, simplifier la gestion de l'hôte qui héberge l'application ou les services, diminuer la divergence entre les différents environnements d'exécution et offrir la possibilité d'intégrer le projet dans un processus d'\href{https://en.wikipedia.org/wiki/Continuous_integration}{intégration continue} ou \href{https://en.wikipedia.org/wiki/Continuous_deployment}{déploiement continu}
\item
\textbf{Faciliter l'intégration de nouveaux développeurs dans l'équipe ou de
personnes souhaitant rejoindre le projet}, dans la mesure où la construction d'un nouvel environnement sera grandement facilitée.
\textbf{Faciliter l'intégration de nouveaux développeurs dans l'équipe ou de personnes souhaitant rejoindre le projet}, dans la mesure où la construction d'un nouvel environnement sera grandement facilitée.
\item
\textbf{Minimiser les divergences entre les différents environnemens}
sur lesquels un projet pourrait être déployé, pour éviter de découvrir un bogue sur l'environnement de production qui serait impossible à reproduire ailleurs, simplement parce qu'un des composants varierait
\textbf{Minimiser les divergences entre les différents environnemens} sur lesquels un projet pourrait être déployé, pour éviter de découvrir un bogue sur l'environnement de production qui serait impossible à reproduire ailleurs, simplement parce qu'un des composants varierait
\item
\textbf{Augmenter l'agilité générale du projet}, en permettant une
meilleure évolutivité architecturale et une meilleure mise à l'échelle.
\textbf{Augmenter l'agilité générale du projet}, en permettant une meilleure évolutivité architecturale et une meilleure mise à l'échelle.
\end{enumerate}
En pratique, les points ci-dessus permettront de gagner un temps précieux à la construction d'un nouvel environnement - qu'il soit sur la machine du petit nouveau dans l'équipe, sur un serveur Azure/Heroku/Digital Ocean ou votre nouveau Raspberry Pi Zéro planqué à la cave - et vous feront gagner un temps précieux.
En pratique, les points ci-dessus permettront de gagner un temps précieux à la construction et à la maintenance de n'importe quel environnement - qu'il soit sur la machine du petit nouveau dans l'équipe, sur un serveur Azure/Heroku/Digital Ocean ou sur votre nouveau Raspberry Pi Zéro planqué à la cave.
Pour reprendre plus spécifiquement les différentes idées derrière cette méthode, nous avons:
Pour reprendre plus spécifiquement les différentes idées derrière cette méthode, nous trouvons des conseils concernant:
\begin{enumerate}
\item
Une base de code unique, suivie par un contrôle de versions
\item
Une déclaration explicite et une isolation des dépendances
\item
Configuration applicative
\item
Ressources externes
\item
La séparation des phases de constructions
\item
La mémoire des processus d'exécution
\item
La liaison des ports
\item
Une connaissance et une confiance dans les processus systèmes
\item
La possibilité d'arrêter élégamment l'application, tout en réduisant au minimum son temps de démarrage
\item
La similarité des environnements
\item
La gestion des journaux et des flux d'évènements
\item
L'isolation des tâches administratives
\end{enumerate}
\section{Une base de code unique, suivie par un contrôle de versions}
Chaque déploiement de l'application, et quel que soit l'environnement ciblé, se basera sur une source unique, afin de minimiser les différences que l'on pourrait trouver entre deux environnements d'un même projet.
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}
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}
\includegraphics{images/diagrams/12-factors-1.png}
En résumé:
Comme l'explique Eran Messeri, 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. \cite[pp. 288-298]{devops_handbook}.
Ce dépôt n'est pas uniquement destiné à hébergé le code source, mais également à d'autres artefacts et autres formes de connaissance :
\begin{quote}
\textit{Il y a seulement une base de code par application, mais il y aura plusieurs déploiements de lapplication. Un déploiement est une instance en fonctionnement de lapplication. Cest, par exemple, le site en production, ou bien un ou plusieurs sites de validation. En plus de cela, chaque développeur a une copie de lapplication qui fonctionne dans son environnement local de développement, ce qui compte également comme un déploiement}. \footnote{\url{https://12factor.net/fr/codebase}}
\end{quote}
\begin{itemize}
\item Standards de configuration (Chef recipes, Puppet manifests, \ldots
\item Outils de déploiement
\item Standards de tests, y compris tout ce qui touche à la sécurité
\item Outils de déploiement de pipeline
\item Outils d'analyse et de monitoring
\item Tutoriaux
\end{itemize}
Comme l'explique Eran Messeri, ingénieur dans le groupe Google Developer Infrastructure: "\textit{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}. \cite[pp. 288-298]{devops_handbook}.
Ce dépôt n'est pas uniquement destiné à hébergé le code source, mais également à d'autres artefacts et autres formes de connaissance, comme les standards de configuration (Chef recipes, Puppet manifests, \ldots), outils de déploiement, standards de tests (y compris ce qui touche à la sécurité), outils d'analyse et de monitoring ou tutoriaux.
\section{Déclaration explicite et isolation des dépendances}
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.
Ceci permet d'éviter que l'application n'utilise une dépendance qui ne soit déjà installée sur un des sytèmes de développement, et qu'elle soit difficile, voire impossible, à répercuter sur un autre environnement.
Dans le cas de Python, cela pourra être fait au travers de \href{https://pypi.org/project/pip/}{PIP - Package Installer for Python} ou \href{https://python-poetry.org/}{Poetry}.
La majorité des langages moderners proposent des mécanismes similaires (\href{https://rubygems.org/}{Gem} pour Ruby, \href{https://www.npmjs.com/}{NPM} pour NodeJS, \ldots)
Dans tous les cas, chaque application doit disposer d'un environnement sain, qui lui est assigné. Vu le peu de ressources que cela coûte, il ne faut pas s'en priver.
Chaque installation ou configuration doit être toujours réalisée de la même manière, et doit pouvoir être répétée quel que soit l'environnement cible.
Ceci permet d'éviter que l'application n'utilise une dépendance qui ne soit installée que sur l'un des sytèmes de développement, et qu'elle soit difficile, voire impossible, à réinstaller sur un autre environnement.
Chaque dépendance devra déclarer et épingler dans un fichier la version nécessaire.
Lors de la création d'un nouvel environnement vierge, il suffira d'utiliser ce fichier comme paramètre afin d'installer les prérequis au bon fonctionnement de notre application.
Ceci autorise une reproductibilité quasi parfaite de l'environnement.
Chaque dépendance devra être déclarée dans un fichier présent au niveau de la base de code.
Lors de la création d'un nouvel environnement vierge, il suffira d'utiliser ce fichier comme paramètre afin d'installer les prérequis au bon fonctionnement de notre application, afin d'assurer une reproductibilité quasi parfaite de l'environnement d'exécution.
Il est important de bien "épingler" les versions liées aux dépendances de l'application. Cela peut éviter des effets de bord comme une nouvelle version d'une librairie dans laquelle un bug aurait pu avoir été introduit.
Parce qu'il arrive que ce genre de problème apparaisse, et lorsque ce sera le cas, ce sera systématiquement au mauvais moment \footnote{Le paquet PyLint dépend par exemple d'Astroid; \href{https://github.com/PyCQA/pylint-django/issues/343}{en janvier 2022}, ce dernier a été mis à jour sans respecter le principe de versions sémantiques et introduisant une régression. PyLint spécifiait que sa dépendance avec Astroid devait respecter une version ~2.9. Lors de sa mise à jour en 2.9.1, Astroid a introduit un changement majeur, qui faisait planter Pylint. L'épinglage explicite aurait pu éviter ceci.}
Il est important de bien "épingler" les versions liées aux dépendances de l'application.
Ceci peut éviter des effets de bord comme une nouvelle version d'une librairie dans laquelle un bug aurait pu avoir été introduit.\footnote{Le paquet PyLint dépend par exemple d'Astroid; \href{https://github.com/PyCQA/pylint-django/issues/343}{en janvier 2022}, ce dernier a été mis à jour sans respecter le principe de versions sémantiques et introduisant une régression. PyLint spécifiait que sa dépendance avec Astroid devait respecter une version ~2.9. Lors de sa mise à jour en 2.9.1, Astroid a introduit un changement majeur, qui faisait planter Pylint. L'épinglage explicite aurait pu éviter ceci.}.
Dans le cas de Python, la déclaration explicite et l'épinglage pourront notamment être réalisés au travers de \href{https://pypi.org/project/pip/}{PIP} ou \href{https://python-poetry.org/}{Poetry}.
La majorité des langages modernes proposent des mécanismes similaires (\href{https://rubygems.org/}{Gem} pour Ruby, \href{https://www.npmjs.com/}{NPM} pour NodeJS, \ldots)
\section{Configuration applicative}

View File

@ -23,17 +23,55 @@ Si vous manquez d'idées ou si vous ne savez pas par où commencer:
Si vous hésitez, et même si Codium n'est pas le plus léger (la faute à \href{https://www.electronjs.org/}{Electron}\ldots\hspace{0pt}), il fera correctement son travail (à savoir : faciliter le vôtre), en intégrant suffisament de fonctionnalités qui gâteront les papilles émoustillées du développeur impatient.
\begin{figure}[H]
\centering
\includegraphics{images/environment/codium.png}
\caption{Codium en action}
\centering
\scalebox{1.0}{\includegraphics[max size={\textwidth}{\textheight}]{images/environment/codium.png}}
\caption{Codium en action}
\end{figure}
\subsection{Configuration}
\subsection{Greffons}
VSCodium permet également de définir certaines clés de configuration globalement ou au niveau d'un projet.
Celle qui nous semble critique, indispensable et primordial est la suppression automatique des espaces en fin de ligne, qui facilite énormément la relecture de \textit{commits} et la collaboration entre intervenants.
\subsection{settings.json}
\begin{minted}{js}
/* fichier placé habituellement dans ~/.config/code/User/settings.json */
\subsection{Mode debug - launch.json}
{
[...]
"files.trimTrailingWhitespace": true,
}
\end{minted}
Nous pouvons également noter la possibilité d'installer des greffons (dont un gestionnaire d'interpréteur Python), l'intégration poussée de Git \index{git} ou l'énorme support de plein de langages de programmation ou de mise en forme: Go, XML, HTML, Java, C\#, PHP, LaTeX, \ldots, ainsi que tout l'atirail d'aides à l'utilisation de Docker.
\subsection{Mode debug}
Le débugger intégré vous permettra de spécifier le point d'entrée à utiliser, de placer des points d'arrêt (éventuellement conditionnés par certaines valeurs attribuées à des variables), de lancer une analyse sur les variables et contextes, sur la pile d'appels, ...
Bref: de savoir où vous en êtes et pourquoi vous êtes là.
Ce débugger fonctionne soit sur le fichier courant (déconseillé), soit \textit{via} un fichier \texttt{launch.json} que vous pourrez placer dans le répertoire \texttt{.vscode} placé à la racine de votre projet.
Pour une application Django, ce fichier contiendra par exemple la configuration suivante:
\begin{minted}{js}
{
"version": "0.2.0",
"configurations": [
{
"name": "Python Django",
"type": "python",
"request": "launch",
"program": "${workspaceFolder}/manage.py",
"args": [
"runserver"
],
"django": true,
"justMyCode": true
}
]
}
\end{minted}
Les \textit{configurations} peuvent être multiples, et nous pouvons voir que l'objectif de cette configuration-ci est de démarrer la commande \texttt{\$\{workspaceFolder\}/manage.py}, avec le paramètre \texttt{runserver}, ce qui aura pour effet de démarrer l'exécution du code dans une enveloppe sécurisée et plombée de capteurs en tout genre qui faciliteront énormément votre travail de recherche et d'introspection du code.
\section{Terminal}
@ -52,9 +90,8 @@ A nouveau, si vous manquez d'idées :
\end{enumerate}
\begin{figure}[H]
\centering
\includegraphics{images/environment/terminal.png}
\caption{Mise en abîme}
\centering
\scalebox{1.0}{\includegraphics[max size={\textwidth}{\textheight}]{images/environment/terminal.png}}
\end{figure}
@ -63,9 +100,13 @@ A nouveau, si vous manquez d'idées :
Nous en auront besoin pour gé(né)rer des phrases secrètes pour nos applications.
Si vous n'en utilisez pas déjà un, partez sur \href{https://keepassxc.org/}{KeepassXC}: il est multi-plateformes, suivi et s'intègre correctement aux différents environnements, tout en restant accessible.
\includegraphics{images/environment/keepass.png}
\begin{figure}[H]
\centering
\scalebox{1.0}{\includegraphics[max size={\textwidth}{\textheight}]{images/environment/keepass.png}}
\end{figure}
La finalité de cette application va être de centraliser la gestion de vos phrases de passe, pour les accès aux bases de données, services en ligne, etc.
Il existe des alternatives, comme Bitwarden, qui proposent des services libres, gratuits ou payants.
\subsection{Un système de gestion de versions}
@ -75,9 +116,9 @@ Il est une aide précieuse pour développer rapidement des preuves de concept, s
Ses deux plus gros défauts concernent sa courbe d'apprentissage pour les nouveaux venus et la complexité des actions qu'il permet de réaliser.
\begin{figure}[H]
\centering
\includegraphics{images/xkcd-1597-git.png}
\caption{\url{https://xkcd.com/1597/}}
\centering
\scalebox{1.0}{\includegraphics[max size={\textwidth}{\textheight}]{images/xkcd-1597-git.png}}
\caption{\url{https://xkcd.com/1597/}}
\end{figure}
\begin{enumerate}
@ -96,9 +137,9 @@ Ses deux plus gros défauts concernent sa courbe d'apprentissage pour les nouvea
\end{enumerate}
\begin{figure}[H]
\centering
\includegraphics{images/diagrams/git-workflow.png}
\caption{Git en action}
\centering
\scalebox{1.0}{\includegraphics[max size={\textwidth}{\textheight}]{images/diagrams/git-workflow.png}}
\caption{Git en action}
\end{figure}
Cas pratique: vous développez une nouvelle fonctionnalité qui va révolutionner le monde de demain et d'après-demain, quand, tout à coup (!), vous vous rendez compte que vous avez perdu votre conformité aux normes PCI parce les données des titulaires de cartes ne sont pas isolées correctement.
@ -126,7 +167,6 @@ Les plus connues sont \href{https://www.gitflow.com/}{Gitflow} et \href{https://
La gestion de versions de fichiers permet de conserver un historique de toutes les modifications enregistrées, associées à un horodatage et une description.
\subsection{Décrire ses changements}
La description d'un changement se fait \emph{via} la commande \texttt{git\ commit}.
@ -137,7 +177,7 @@ De plus, la plupart des plateformes de dépôts présenteront ces informations d
\begin{figure}[H]
\centering
\includegraphics{images/environment/gitea-commit-message.png}
\scalebox{1.0}{\includegraphics[max size={\textwidth}{\textheight}]{images/environment/gitea-commit-message.png}}
\caption{Un exemple de commit affiché dans Gitea}
\end{figure}

Binary file not shown.

After

Width:  |  Height:  |  Size: 25 KiB