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é et accessible depuis un
Il est du coup probable d'oublier une partie des désidérata, de zapper une fonctionnalité essentielle ou simplement de passer énormément de temps à adapter les sources pour qu'elles puissent être mises à
disposition sur un environnement en particulier, une fois que leur développement aura été finalisé, testé et validé.
Un bon déploiement ne doit pas dépendre de dizaines de petits scripts éparpillés sur le disque.
L'objectif est qu'il soit rapide et fiable.
Ceci peut être atteint au travers d'un partitionnement correct, incluant le fait que le composant principal s'assure que chaque sous-composant est correctement démarré intégré et supervisé.
Aborder le déploiement dès le début permet également de rédiger dès le début les procédures d'installation, de mises à jour et de sauvegardes.
A la fin de chaque intervalle de développement, les fonctionnalités auront dû avoir été intégrées, testées, fonctionnelles et un code propre, démontrable dans un environnement similaire à un environnement de production, et créées à partir d'un tronc commun au développement
Because value is created only when our services are running into production, we must ensure that we are not only delivering fast flow, but that our deployments can also be performed without causing chaos and
disruptions such as service outages, service impairments, or security or compliance failures.
Le serveur que Django met à notre disposition \emph{via} la commande \texttt{runserver} est extrêmement pratique, mais il est uniquement prévu pour la phase développement.
De même, Django propose par défaut une base de données SQLite, qui fonctionne parfaitement dès lors que l'on connait ses limites et que l'on se limite à un utilisateur à la fois.
\item Il est légitime que la base de donnée soit capable de supporter plusieurs utilisateurs et connexions simultanés.
En restant avec les paramètres par défaut, il est plus que probable que vous rencontriez rapidement des erreurs de verrou parce qu'un autre processus a déjà pris la main pour écrire ses données. En bref, vous avez quelque chose qui fonctionne, qui répond à un besoin, mais qui va attirer la grogne de ses utilisateurs pour des problèmes de latences, pour des erreurs de verrou ou simplement parce que le serveur répondra trop lentement.
L'objectif de cette partie est de parcourir les différentes possibilités qui s'offrent à nous en termes de déploiement, tout en faisant en sorte que le code soit le moins couplé possible à sa destination de
production. L'objectif est donc de faire en sorte qu'une même application puisse être hébergées par plusieurs hôtes sans avoir à subir de modifications. Nous vous renvoyons vers les 12-facteurs dont nous
avons déjà parlé et qui vous énormément nous aider, puisque ce sont des variables d'environnement qui vont réellement piloter le câblage entre l'application, ses composants et son hébergement.
Définir l'infrastructure et les composants nécessaires à notre application
\item
Configurer l'hôte qui hébergera l'application et y déployer notre application: dans une machine physique, virtuelle ou dans un container. Nous aborderons aussi les déploiements via Ansible et Salt. A ce stade, nous aurons déjà une application disponible.
\item
Configurer les outils nécessaires à la bonne exécution de ce code et de ses fonctionnalités: les différentes méthodes de supervision de l'application, comment analyser les fichiers de logs, comment intercepter correctement une erreur si elle se présente et comment remonter correctement l'information.
Sur une machine hôte, en embarquant tous les composants sur un même serveur.
Ce ne sera pas idéal, puisqu'il ne sera pas possible de configurer un \emph{load balancer}, de routeur plusieurs basées de données, mais ce sera le premier cas de figure.
\item
Dans des containers, avec Docker-Compose (et à nouveau sur un seul serveur)
Sur une \textbf{Plateforme en tant que Service} (ou plus simplement, \textbf{PaaSPaaS}), pour faire abstraction de toute la couche de configuration du serveur.
Vous noterez que l'ensemble des composants utilisés sont \textit{Open source}:
\begin{quote}
When I built my first company starting in 1999, it cost \$2.5 million in infrastructure just to get started and another \$2.5 million in team costs to code, launch, manage, market and sell our software [\ldots].
The first major change in our industry was imperceptible to us as an industry.
It was driven by the introduction of open-source software, most notably what was called the LAMP stack.
Linux (instead of UNIX), Apache (web server software), MySQL (instead of Oracle) and PHP.
Of course there were variants - we preferred PostGres to MySQL and many people used other programming languages than PHP.
Open source became a movement - a mentality: Suddenly infrastructure software was nearly free.
We paid 10\% of the normal costs for the software and that money was software support.
A 90\% disruption in cost spawns innovation - belive me.
-- Mark Suster
\end{quote}
Dans tous les cas, la disponibilité de logiciels et librairies \textit{open source}, ainsi que des plateformes d'hébergements (comme Amazon Web Services ou Heroku) plus accessibles signifient qu'une startup n'a plus besoin d'investir des millions pour démarrer \cite[p. 25]{roads_and_bridges}\footnote{Avant que les logiciels libres n'existent, les entreprises technologiques traitaient les logiciels comme n'importe quel produit payant: une équipe d'employés construisait les nouveaux logiciels en interne, puis les vendait au public.
Le développement logiciel avait donc un business-model très clair, mais ceci venait en contrepartie avec des coûts énormes.
Les logiciels propriétaires demandaient des équipes complètes pour supporter le développement, tandis qu'il fallait également des vendeurs, une équipe marketing et un troupeau d'avocats. \cite[p. 33]{roads_and_bridges}}.