reworks parts
This commit is contained in:
parent
a8dbfa3b8e
commit
5ea82e0af6
Binary file not shown.
|
Before Width: | Height: | Size: 9.5 KiB |
|
|
@ -1,69 +0,0 @@
|
|||
.. Gwift documentation master file, created by
|
||||
sphinx-quickstart on Wed Oct 28 18:48:30 2015.
|
||||
You can adapt this file completely to your liking, but it should at least
|
||||
contain the root `toctree` directive.
|
||||
|
||||
Welcome to Gwift's documentation!
|
||||
=================================
|
||||
|
||||
#####################
|
||||
Deep dive into Django
|
||||
#####################
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:numbered:
|
||||
|
||||
intro
|
||||
|
||||
#################
|
||||
Espace de travail
|
||||
#################
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:numbered:
|
||||
|
||||
gwift
|
||||
integration
|
||||
|
||||
|
||||
#################################
|
||||
Déploiement et mise en production
|
||||
#################################
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:numbered:
|
||||
|
||||
production
|
||||
|
||||
################################
|
||||
Modélisation et concepts de base
|
||||
################################
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:numbered:
|
||||
|
||||
admin
|
||||
mvc
|
||||
forms
|
||||
auth
|
||||
|
||||
#########
|
||||
En résumé
|
||||
#########
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:numbered:
|
||||
|
||||
summary
|
||||
|
||||
Indices and tables
|
||||
==================
|
||||
|
||||
* :ref:`genindex`
|
||||
* :ref:`modindex`
|
||||
* :ref:`search`
|
||||
|
|
@ -13,56 +13,37 @@ L'idée du texte ci-dessous est de jeter les bases d'un bon développement, en s
|
|||
|
||||
Ces idées ne s'appliquent pas uniquement à Django et à son cadre de travail, ni même au langage Python. Juste que ces deux bidules sont de bons candidats et que le cadre de travail est bien défini et suffisamment flexible.
|
||||
|
||||
Django se présente comme un `Framework Web pour perfectionnistes ayant des deadlines <https://www.djangoproject.com/>`_.
|
||||
Django se présente comme un "Framework Web pour perfectionnistes ayant des deadlines" [https://www.djangoproject.com/].
|
||||
|
||||
Django suit quelques principes <https://docs.djangoproject.com/en/dev/misc/design-philosophies/>:
|
||||
Django suit link:quelques principes[https://docs.djangoproject.com/en/dev/misc/design-philosophies/].
|
||||
|
||||
* Faible couplage et forte cohésion, pour que chaque composant ait son indépendance.
|
||||
* Moins de code, plus de fonctionnalités.
|
||||
* `Don't repeat yourself <https://fr.wikipedia.org/wiki/Sec>`_: ne pas se répéter!
|
||||
* Rapidité du développement (après une courbe d'apprentissage relativement ardue, malgré tout)
|
||||
* link:Don't repeat yourself[https://fr.wikipedia.org/wiki/Sec]: ne pas se répéter!
|
||||
* Rapidité du développement (après une petite courbe d'apprentissage un peu ardue au début ;-))
|
||||
|
||||
Mis côté à côté, l'application de ces principes permet une meilleure stabilité du projet. Dans la suite de ce chapitre, on verra comment configurer l'environnement, comment installer Django de manière isolée et comment démarrer un nouveau projet. On verra comment gérer correctement les dépendances, les versions et comment applique un score sur note code.
|
||||
Mis côte à côte, l'application de ces principes permet une meilleure stabilité du projet.
|
||||
|
||||
Finalement, on verra aussique la configuration proposée par défaut par le framework n'est pas idéale pour la majorité des cas.
|
||||
Dans la première partie, on verra comment configurer l'environnement, comment installer Django de manière isolée et comment démarrer un nouveau projet. On verra comment gérer correctement les dépendances, les versions et comment applique un score sur note code.
|
||||
On verra aussique la configuration proposée par défaut par le framework n'est pas idéale pour la majorité des cas.
|
||||
|
||||
Pour cela, on présentera différents outils (mypy, flake8, black, ...), la rédaction de tests unitaires et d'intégration pour limiter les régressions, les règles de nomenclature et de contrôle du contenu, ainsi que les bonnes étapes à suivre pour arriver à un déploiement rapide et fonctionnel avec peu d'efforts.
|
||||
|
||||
Dans la seconde partie, on détaillera précisément les étapes de déploiement, avec la description et la configuration de l'infrastructure, ainsi que des exemples concrets de déploiement sur deux distributions principales (Debian et CentOS), ainsi que l'utilisation de Docker et Docker-Compose.
|
||||
|
||||
On abordera également la supervision et la mise à jour d'une application existante, en respectant les bonnes pratiques d'administration système.
|
||||
|
||||
Dans la troisième partie, on abordera les grands principes de modélisation, en suivant les lignes de conduites du cadre de travail. On abordera les concepts clés qui permettent à une application de rester maintenable, les formulaires et leurs validations, les migrations de données et l'administration.
|
||||
|
||||
Dans la quatrième partie, on mettra ces concepts en pratique en présentant le développement d'une "vraie" application: définition des tables, gestion des utilisateurs, ... et mise à disposition!
|
||||
|
||||
Et tout ça à un seul et même endroit. Oui. :-)
|
||||
|
||||
Bonne lecture.
|
||||
|
||||
= Environnement de travail
|
||||
include::part-1-workspace/main.adoc[]
|
||||
|
||||
Avant de démarrer le développement, il est nécessaire de passer un peu de temps sur la configuration de l'environnement.
|
||||
|
||||
Les morceaux de code seront développés pour Python3.4+ et Django 1.8+. Ils nécessiteront peut-être quelques adaptations pour fonctionner sur une version antérieure.
|
||||
|
||||
**Remarque** : les commandes qui seront exécutés dans ce livre le seront depuis un shell sous GNU/Linux. Certaines devront donc être adaptées si vous êtes dans un autre environnemnet.
|
||||
|
||||
include::toolchain/12-factors.adoc[]
|
||||
|
||||
include::toolchain/venvs.adoc[]
|
||||
|
||||
include::toolchain/django.adoc[]
|
||||
|
||||
include::toolchain/maintainable-applications.adoc[]
|
||||
|
||||
include::toolchain/tools.adoc[]
|
||||
|
||||
include::toolchain/external_tools.adoc[]
|
||||
|
||||
include::toolchain/summary.adoc[]
|
||||
|
||||
|
||||
= Déploiement
|
||||
Et sécurisation du serveur.
|
||||
|
||||
include::deploy/index.adoc[]
|
||||
|
||||
include::deploy/centos.adoc[]
|
||||
|
||||
include::deploy/database.adoc[]
|
||||
include::part-2-deployment/main.adoc[]
|
||||
|
||||
= Modélisation
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,42 @@
|
|||
== Construire des applications maintables
|
||||
|
||||
Pour la méthode de travail et de développement, on va se baser sur les https://12factor.net/fr/[The Twelve-factor App] - ou plus simplement les *12 facteurs*.
|
||||
|
||||
L'idée derrière cette méthode consiste à pousser les concepts suivants (repris grossièrement de la https://12factor.net/fr/[page d'introduction] :
|
||||
|
||||
. Faciliter la mise en place de phases d'automatisation; plus simplement, faciliter les mises à jour applicatives, simplifier la gestion de l'hôte, diminuer la divergence entre les différents environnements d'exécution et offrir la possibilité d'intégrer le projet dans un processus d'https://en.wikipedia.org/wiki/Continuous_integration[intégration continue]/link:https://en.wikipedia.org/wiki/Continuous_deployment[déploiement continu]
|
||||
. Faciliter la mise à pied de nouveaux développeurs ou de personnes souhaitant rejoindre le projet.
|
||||
. Faciliter XXX
|
||||
. Augmenter l'agilité générale du projet, en permettant une meilleure évolutivité architecturale et une meilleure mise à l'échelle - _Vous avez 5000 utilisateurs en plus? Ajoutez un serveur et on n'en parle plus ;-)_.
|
||||
|
||||
En pratique, les idées planquées derrière les points ci-dessus permettront de monter facilement 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 caché à la cave.
|
||||
|
||||
Pour reprendre de manière très brute les différentes idées derrière cette méthode, on a:
|
||||
|
||||
NOTE: pensez à retravailler la partie ci-dessous; la version anglophone semble plus compréhensible... :-/
|
||||
|
||||
. Une base de code suivie, avec un système de contrôle de versions, signifie plusieurs déploiements
|
||||
. Déclarez explicitement et isolez les dépendances
|
||||
. Stockez la configuration dans l’environnement
|
||||
|
||||
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 (*?*)
|
||||
. Maximisez la robustesse avec des démarrages rapides et des arrêts gracieux (*?*)
|
||||
. Gardez le développement, la validation et la production aussi proches l'un de l'autre que possible
|
||||
. Traitez les logs comme des flux d’évènements (*?*)
|
||||
. Lancez les processus d’administration et de maintenance comme des one-off-processes (*?*)
|
||||
|
||||
.Concrètement
|
||||
|===
|
||||
|Concept|Concept |Outil |Description
|
||||
|1|Base de code suivie avec un système de contrôle de version| Git, Mercurial, SVN, ...|Chaque déploiement démarre à partir d'une base de code unique. Il n'y pas de dépôt "Prod", "Staging" ou "Dev". Il n'y en a qu'un et un seul.
|
||||
|2|Déclaration explicite et isolation des dépendances| Pyenv, environnements virtuels, RVM, ...|Afin de ne pas perturber les dépendances systèmes, chaque application doit disposer d'un environnement sain par défaut.
|
||||
|3|Configuration dans l'environnement| Fichiers .ENV| Toute clé de configuration (nom du serveur de base de données, adresse d'un service Web externe, clé d'API pour l'interrogation d'une ressource, ...) sera définie directement au niveau de l'hôte - à aucun moment, on ne doit trouver un mot de passe en clair dans le dépôt source ou une valeur susceptible d'évoluer, écrite en dur dans le code.
|
||||
|4|Services externes = ressources locales| Fichiers .ENV| Chaque ressource doit pouvoir être interchangeable avec une autre, sans modification du code source. La solution consiste à passer toutes ces informations (nom du serveur et type de base de données, clé d'authentification, ...) directement via des variables d'environnement.
|
||||
|5|Bien séparer les étapes de construction des étapes de mise à disposition| Capistrano, Gitea, un serveur d'artefacts, ...| L'idée est de pouvoir récupérer une version spécifique du code, sans que celle-ci ne puisse avoir été modifiée. Git permet bien de gérer des versions (au travers des tags), mais ces éléments peuvent sans doute être modifiés directement au travers de l'historique.
|
||||
|===
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 40 KiB |
|
|
@ -0,0 +1,8 @@
|
|||
== Environnement de travail
|
||||
|
||||
Quelques idées: Git, VSCodium[https://vscodium.com/], un terminal (Si vous êtes sous Windows, cmder[https://cmder.net/]).
|
||||
|
||||
Un gestionnaire de base de données ? PHPMyAdmin ou PgAdmin.
|
||||
|
||||
Un IDE ? PyCharm, VSCodium, VIM, ...
|
||||
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
= Environnement de travail
|
||||
|
||||
Avant de démarrer le développement, il est nécessaire de passer un peu de temps sur la configuration de l'environnement.
|
||||
|
||||
Les morceaux de code seront développés pour Python3.6+ et Django 3.0+. Ils nécessiteront peut-être quelques adaptations pour fonctionner sur une version antérieure.
|
||||
|
||||
Django fonctionne sur un link:roulement de trois versions mineures pour une version majeure[https://docs.djangoproject.com/en/dev/internals/release-process/], clôturé par une version LTS (_Long Term Support_).
|
||||
|
||||
image::http://ser-libre.com.ar/wp-content/uploads/2016/11/django.png[Support des versions Django]
|
||||
|
||||
Ce sera une bonne indication à prendre en considération pour nos dépendances, puisqu'en visant une version particulière, on ne devra pratiquement pas se soucier (bon, un peu quand même...) des dépendances à installer, pour peu qu'on reste sous un certain seuil.
|
||||
|
||||
Dans cette partie, on va parler de *méthode de travail*, avec un objectif visé. On peut éviter que l'application ne tourne que sur notre machine et que chaque déploiement ne soit une plaie à gérer. Chaque mise à jour doit se limiter au minimum:
|
||||
|
||||
. démarrer un script,
|
||||
. prévoir un rollback si cela plante
|
||||
. se préparer une tisane en regardant nos flux RSS (si cette technologie existe encore...).
|
||||
|
||||
**Remarque** : les commandes qui seront exécutés dans ce livre le seront depuis un shell sous GNU/Linux. Certaines devront donc être adaptées si vous êtes dans un autre environnemnet.
|
||||
|
||||
include::12-factors.adoc[]
|
||||
|
||||
include::maintainable-applications.adoc[]
|
||||
|
||||
include::environment.adoc[]
|
||||
|
||||
include::venvs.adoc[]
|
||||
|
||||
include::toolchain/django.adoc[]
|
||||
|
||||
include::toolchain/tools.adoc[]
|
||||
|
||||
include::toolchain/external_tools.adoc[]
|
||||
|
||||
include::unit_tests.adoc[]
|
||||
|
||||
include::toolchain/summary.adoc[]
|
||||
|
|
@ -1,65 +1,69 @@
|
|||
== Environnements virtuels
|
||||
== Travailler en isolation
|
||||
|
||||
On va commencer avec la partie la moins funky, mais la plus utile, dans la vie d'un développeur: la gestion et l'isolation des dépendances.
|
||||
On va aborder la gestion et l'isolation des dépendances. Il est tout à fait possible de s'en passer complètement dans le cadre de "petits" projets ou d'applications déployées sur des machines dédiées, et de fonctionner à grand renforts de "sudo" et d'installation globale des dépendances.
|
||||
|
||||
Il est tout à fait possible de s'en passer complètement dans le cadre de "petits" projets ou d'applications déployées sur des machines dédiées, et de fonctionner à grand renforts de "sudo" et d'installation globale des dépendances. Cette pratique est cependant fortement déconseillée pour plusieurs raisons:
|
||||
Cette section est aussi utile pour une personne travaillant seule, que pour transmettre les connaissances à un nouveau membre de l'équipe ou pour déployer l'application elle-même.
|
||||
|
||||
. Pour la reproductibilité d'un environnement spécifique. Cela évite notamment les réponses type "Ca juste marche chez moi", puisqu'on a la possibilité de construire un environnement sain et appliquer des dépendances identiques, quelle que soit la machine hôte.
|
||||
. Il est tout à fait envisagable que deux applications soient déployées sur un même hôte, et nécessitent chacune deux versions différentes d'une même dépendance.
|
||||
Cette pratique est cependant fortement déconseillée pour plusieurs raisons:
|
||||
|
||||
> But it works on my machine! Then, we'll ship your machine.
|
||||
> -- A famous meme, And this is how Docker was born.
|
||||
. Il est tout à fait envisagable que deux applications différentes soient déployées sur un même hôte, et nécessitent chacune deux versions différentes d'une même dépendance.
|
||||
. Pour la reproductibilité d'un environnement spécifique. Cela évite notamment les réponses type "Ca juste marche chez moi", puisque la construction d'un nouvel environnement fait partie de la documentation du projet; grace à elle, on a la possibilité de construire un environnement sain et d'appliquer des dépendances identiques, quelle que soit la machine hôte.
|
||||
|
||||
Nous allons utiliser le module `venv` afin de créer un `environnement virtuel <http://sametmax.com/les-environnement-virtuels-python-virtualenv-et-virtualenvwrapper/>`_ pour python.
|
||||
image::https://res.cloudinary.com/teepublic/image/private/s--hOdhXtVV--/t_Preview/b_rgb:ffffff,c_limit,f_jpg,h_630,q_90,w_630/v1464028809/production/designs/521845_1.jpg
|
||||
|
||||
NOTE: auparavant, on utilisait `virtualenvwrapper`. mais cela fait plusieurs années que je ne l'utilise plus. On l'intègre quand même ?
|
||||
Depuis la version 3.5 de Python, le module `venv` est link:recommandé[https://docs.python.org/3/library/venv.html] afin de créer un environnement virtuel.
|
||||
|
||||
Il existe plusieurs autres modules permettant d'arriver au même résultat, avec quelques avantages et inconvénients pour chacun d'entre eux.
|
||||
|
||||
NOTE: parler ici de poetry, pip, pipenv et rebondir sur le point 2 des 12 facteurs.
|
||||
|
||||
=== Création de l'environnement virtuel
|
||||
|
||||
Commencons par créer un environnement virtuel, afin d'y stocker les dépendances. Lancez `python3 -m venv gwift-env`.
|
||||
|
||||
[source,bash]
|
||||
---
|
||||
Intégrer les résultats de la création de l'environnement
|
||||
---
|
||||
Commencons par créer un environnement virtuel, afin d'y stocker les dépendances. Placez-vous dans le répertoire dans lequel vous pourrez stocker tous vos environnements (ces environnements sont indépendants des sources; ils peuvent donc être placés n'importe où sur votre disque - évitez peut-être juste de les mettre pile dans le même répertoire que votre code source). Lancez ensuite la commande `python3 -m venv gwift-env`.
|
||||
|
||||
Ceci créera l'arborescence de fichiers suivante, qui peut à nouveau être un peu différente en fonction du système d'exploitation:
|
||||
|
||||
.. code-block:: shell
|
||||
[source,bash]
|
||||
---
|
||||
fred@aerys:~/Sources/.venvs/gwift-env$ ls
|
||||
bin include lib lib64 pyvenv.cfg share
|
||||
---
|
||||
|
||||
$ ls .virtualenvs/gwift-env
|
||||
bin include lib
|
||||
|
||||
Nous pouvons ensuite l'activer grâce à la commande `source gwift-env`.
|
||||
Nous pouvons ensuite l'activer grâce à la commande `source gwift-env/bin/activate`.
|
||||
|
||||
[source,bash]
|
||||
---
|
||||
Intégrer les résultats de l'accès de l'environnement
|
||||
(gwift-env) fred@aerys:~/Sources/.venvs/gwift-env$ <1>
|
||||
---
|
||||
<1> Le *shell* signale que nous sommes bien dans l'environnement `gwift-env`.
|
||||
|
||||
Le *shell* signale que nous sommes bien dans l'environnement ``gwift-env`` en l'affichant avant le ``$``. Par la suite, nous considérerons que l'environnement virtuel est toujours activé, même si ``gwift-env`` n'est pas présent devant chaque ``$``.
|
||||
Par la suite, nous considérerons que l'environnement virtuel est toujours activé, même si ``gwift-env`` à chaque snippet de code.
|
||||
|
||||
A présent, tous les binaires de cet environnement prendront le pas sur les binaires du système. De la même manière, une variable ``PATH`` propre est définie et utilisée, afin que les librairies Python y soient stockées. C'est donc dans cet environnement virtuel que nous retrouverons le code source de Django, ainsi que des librairies externes pour Python une fois que nous les aurons installées.
|
||||
A présent que l'environnement est activé, tous les binaires de cet environnement prendront le pas sur les binaires du système. De la même manière, une variable `PATH` propre est définie et utilisée, afin que les librairies Python y soient stockées. C'est donc dans cet environnement virtuel que nous retrouverons le code source de Django, ainsi que des librairies externes pour Python une fois que nous les aurons installées.
|
||||
|
||||
Pour désactiver l'environnement virtuel, il suffira d'utiliser la commande ``deactivate``
|
||||
Pour gérer des versions différentes d'une même librairie, il nous suffit de jongler avec autant d'environnements que nécessaires. Une application nécessite une version de Django inférieure à la 2.0 ? On crée un environnement, on l'active et on installe ce qu'il faut.
|
||||
|
||||
Cette technique fonctionnera autant pour un poste de développement que sur les serveurs destinés à recevoir notre application.
|
||||
|
||||
Pour désactiver l'environnement virtuel, il suffit d'utiliser la commande `deactivate`
|
||||
|
||||
=== Installation de Django et création du répertoire de travail
|
||||
|
||||
Comme l'environnement est activé, on peut à présent y installer Django. La librairie restera indépendante du reste du système, et ne polluera pas les autres projets.
|
||||
Après avoir activé l'environnement, on peut à présent y installer Django. La librairie restera indépendante du reste du système, et ne polluera aucun autre projet.
|
||||
|
||||
C'est parti: ``pip install django``!
|
||||
C'est parti: `pip install 'django<3.1' !
|
||||
|
||||
.. code-block:: shell
|
||||
[source,bash]
|
||||
----
|
||||
$ pip install django
|
||||
Collecting django
|
||||
Downloading Django-3.0.5
|
||||
100% |################################|
|
||||
Installing collected packages: django
|
||||
Successfully installed django-3.0.5
|
||||
----
|
||||
|
||||
$ pip install django
|
||||
Collecting django
|
||||
Downloading Django-X.Y.Z
|
||||
100% |################################|
|
||||
Installing collected packages: django
|
||||
Successfully installed django-X.Y.Z
|
||||
|
||||
Les commandes de création d'un nouveau site sont à présent disponibles, la principale étant ``django-admin startproject``. Par la suite, nous utiliserons ``manage.py``, qui constitue un *wrapper* autour de `django-admin`.
|
||||
Les commandes de création d'un nouveau site sont à présent disponibles, la principale étant `django-admin startproject`. Par la suite, nous utiliserons `manage.py`, qui constitue un *wrapper* autour de `django-admin`.
|
||||
|
||||
Pour démarrer notre projet, nous lançons donc ``django-admin startproject gwift``.
|
||||
|
||||
|
|
@ -1,7 +1,9 @@
|
|||
== Un peu de théorie... Les principales étapes
|
||||
= Déploiement
|
||||
|
||||
On va déjà parler de déploiement. Le serveur que django met à notre disposition est prévu uniquement pour le développement: inutile de passer par du code Python pour charger des fichiers statiques (feuilles de style, fichiers JavaScript, images, ...). De même, la base de donnée doit supporter plus qu'un seul utilisateur: SQLite fonctionne très bien dès lors qu'on se limite à un seul utilisateur... Sur une application Web, il est plus que probable que vous rencontriez rapidement des erreurs de base de données verrouillée pour écriture par un autre processus. Il est donc plus que bénéfique de passer sur quelque chose de plus solide.
|
||||
|
||||
Déploiement[https://docs.djangoproject.com/fr/3.0/howto/deployment/].
|
||||
|
||||
Si vous avez suivi les étapes jusqu'ici, vous devriez à peine disposer d'un espace de travail proprement configuré, d'un modèle relativement basique et d'une configuration avec une base de données simpliste. En bref, vous avez quelque chose qui fonctionne, mais qui ressemble de très loin à ce que vous souhaitez au final.
|
||||
|
||||
Il y a une raison très simple à aborder le déploiement dès maintenant: à trop attendre et à peaufiner son développement en local, on en oublie que sa finalité sera de se retrouver exposé sur un serveur. On risque d'avoir oublié une partie des désidérata, d'avoir zappé une fonctionnalité essentielle ou simplement de passer énormément de temps à adapter les sources pour qu'elles fonctionnent sur un environnement en particulier.
|
||||
|
|
@ -15,6 +17,12 @@ Dans cette partie, on abordera les points suivants:
|
|||
* Les différentes méthodes de supervision de l'application: comment analyser les fichiers de logs et comment intercepter correctement une erreur si elle se présente et comment remonter l'information.
|
||||
* Une partie sur la sécurité et la sécurisation de l'hôte.
|
||||
|
||||
include::infrastructure.adoc[]
|
||||
|
||||
include::centos+debian.adoc[]
|
||||
|
||||
include::database.adoc[]
|
||||
|
||||
=== Définition de l'infrastructure
|
||||
|
||||
Comme on l'a vu dans la première partie, Django est un framework complet, intégrant tous les mécanismes nécessaires à la bonne évolution d'une application. On peut ainsi commencer petit, et suivre l'évolution des besoins en fonction de la charge estimée ou ressentie, ajouter un mécanisme de mise en cache, des logiciels de suivi, ...
|
||||
|
|
@ -1,39 +0,0 @@
|
|||
== Méthodologie de travail
|
||||
|
||||
Pour la méthode de travail et de développement, on va se baser sur les https://12factor.net/fr/[The Twelve-factor App] - ou plus simplement les *12 facteurs*.
|
||||
|
||||
L'idée derrière cette méthode consiste à pousser les concepts suivants (repris grossièrement de la https://12factor.net/fr/[page d'introduction] :
|
||||
|
||||
. Faciliter la mise en place de phases d'automatisation; plus simplement, faciliter les mises à jour applicatives, simplifier la gestion de l'hôte, diminuer la divergence entre les différents environnements d'exécution et offrir la possibilité d'intégrer le projet dans un processus d'https://en.wikipedia.org/wiki/Continuous_integration[intégration continue]/link:https://en.wikipedia.org/wiki/Continuous_deployment[déploiement continu]
|
||||
. Faciliter la mise à pied de nouveaux développeurs ou de personnes souhaitant rejoindre le projet.
|
||||
. Faciliter
|
||||
. Augmenter l'agilité générale du projet, en permettant une meilleure évolutivité architecturale et une meilleure mise à l'échelle - _Vous avez 5000 utilisateurs en plus? Ajoutez un serveur et on n'en parle plus ;-)_.
|
||||
|
||||
En pratique, les idées planquées derrière les quelques phrases ci-dessus permettront de monter facilement un nouvel environnement - qu'il soit sur la machine du petit nouveau ou sur un serveur Azure, Heroku, Digital Ocean ou votre nouveau Raspberry Pi Zéro caché à la cave.
|
||||
|
||||
Pour reprendre de manière très brute les différentes idées derrière cette méthode, on a:
|
||||
|
||||
NOTE: pensez à retravailler la partie ci-dessous; la version anglophone semble plus compréhensible... :-/
|
||||
|
||||
. Une base de code suivie avec un système de contrôle de version, plusieurs déploiements
|
||||
. Déclarez explicitement et isolez les dépendances
|
||||
. Stockez la configuration dans l’environnement
|
||||
. 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
|
||||
. Maximisez la robustesse avec des démarrages rapides et des arrêts gracieux
|
||||
. Gardez le développement, la validation et la production aussi proches que possible
|
||||
. Traitez les logs comme des flux d’évènements
|
||||
. Lancez les processus d’administration et de maintenance comme des one-off-processes
|
||||
|
||||
.Concrètement
|
||||
|===
|
||||
|Concept |Outil |Description
|
||||
|Base de code suivie avec un système de contrôle de version| Git, Mercurial, SVN, ...|Chaque déploiement démarre à partir d'une base de code unique. Il n'y pas de dépôt "Prod", "Staging" ou "Dev". Il n'y en a qu'un et un seul.
|
||||
|Déclaration explicite et isolation des dépendances| Pyenv, environnements virtuels, RVM, ...|Afin de ne pas perturber les dépendances systèmes, chaque application doit disposer d'un environnement sain par défaut.
|
||||
|Configuration dans l'environnement| Fichiers .ENV| Toute clé de configuration (nom du serveur de base de données, adresse d'un service Web externe, clé d'API pour l'interrogation d'une ressource, ...) sera définie directement au niveau de l'hôte - à aucun moment, on ne doit trouver un mot de passe en clair dans le dépôt source ou une valeur susceptible d'évoluer, écrite en dur dans le code.
|
||||
|Services externes = ressources locales| Fichiers .ENV| Chaque ressource doit pouvoir être interchangeable avec une autre, sans modification du code source. La solution consiste à passer toutes ces informations (nom du serveur et type de base de données, clé d'authentification, ...) directement via des variables d'environnement.
|
||||
|Bien séparer les étapes de construction des étapes de mise à disposition| Capistrano, Gitea, un serveur d'artefacts, ...| L'idée est de pouvoir récupérer une version spécifique du code, sans que celle-ci ne puisse avoir été modifiée. Git permet bien de gérer des versions (au travers des tags), mais ces éléments peuvent sans doute être modifiés directement au travers de l'historique.
|
||||
|===
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
== Construire des applications maintenables
|
||||
|
||||
Pour cette section, je me base d'un résumé de l'ebook **Building Maintenable Software** disponible chez `O'Reilly <http://shop.oreilly.com/product/0636920049555.do`_ qui vaut clairement le détour pour poser les bases d'un projet.
|
||||
Pour cette section, je me base d'un résumé de l'ebook **Building Maintenable Software** disponible chez link:O'Reilly[http://shop.oreilly.com/product/0636920049555.do].
|
||||
|
||||
Ce livre répartit un ensemble de conseils parmi quatre niveaux de composants:
|
||||
|
||||
|
|
@ -34,3 +34,4 @@ Ce livre répartit un ensemble de conseils parmi quatre niveaux de composants:
|
|||
|
||||
Par rapport aux points repris ci-dessus, l'environnement Python et le framework Django proposent un ensemble d'outils intégrés qui permettent de répondre à chaque point. Avant d'aller plus loin, donc, un petit point sur les conventions, les tests (unitaires, orientés comportement, basés sur la documentation, ...), la gestion de version du code et sur la documentation. Plus que dans tout langage compilé, ceux-ci sont pratiquement obligatoires. Vous pourrez les voir comme une perte de temps dans un premier temps, mais nous vous promettons qu'ils vous en feront gagner par la suite.
|
||||
|
||||
NOTE: parlez des principes SOLID
|
||||
Loading…
Reference in New Issue