De l'idée sur votre ordinateur à une application que les gens peuvent vraiment utiliser
Toute application commence de la même manière : par une idée dans la tête de quelqu'un. Vous voulez peut-être résoudre un problème que vous avez remarqué, ou votre équipe vous a demandé de construire quelque chose de nouveau. Quelle que soit la raison, à un moment donné, vous ouvrez votre ordinateur et commencez à écrire du code.
Sur votre machine, tout semble facile. Vous exécutez l'application, voyez l'interface, testez quelques fonctionnalités, et tout fonctionne. Si quelque chose casse, vous le réparez et relancez. Vous êtes le seul à voir l'application. Personne d'autre n'est perturbé si l'application plante ou génère des erreurs.
Mais l'idée de construire une application s'arrête rarement à votre ordinateur. Vous l'avez construite pour que d'autres puissent l'utiliser — amis, clients, collègues au bureau, ou le public. Dès que quelqu'un d'autre doit y accéder, une question très basique apparaît : où cette application va-t-elle tourner pour que d'autres puissent l'atteindre ?
Votre ordinateur n'est pas le bon endroit. Les ordinateurs portables s'éteignent, tombent en panne de batterie, sont emportés à la maison, ou se connectent à des réseaux qui bloquent l'accès extérieur. Si votre application ne tourne que sur votre machine, les autres ne peuvent l'utiliser que lorsque vous êtes devant et que votre réseau autorise l'accès externe. Ce n'est ni pratique ni fiable.
Le premier vrai besoin : un endroit pour exécuter
Une application doit vivre quelque part qui reste allumé, reste connecté au réseau, et peut être atteint par qui vous autorisez. Cet endroit s'appelle un serveur. Un serveur peut être un ordinateur physique que vous gérez vous-même, ou une machine virtuelle que vous louez chez un fournisseur cloud. Ce qui compte, c'est qu'un serveur est un ordinateur dont le travail principal est d'exécuter des applications et de servir les requêtes des utilisateurs.
Le processus qui consiste à placer votre application sur un serveur pour que d'autres puissent y accéder est le premier vrai besoin qui apparaît dans la livraison de logiciels. Ce besoin est souvent appelé hébergement. Vous devez décider où l'application sera hébergée, comment envoyer votre code sur ce serveur, et comment vous assurer que l'application s'exécute effectivement une fois arrivée.
Le serveur utilisé pour exécuter l'application dont dépendent les utilisateurs réels s'appelle l'environnement de production. Le mot "production" indique qu'il ne s'agit plus d'une zone de test. C'est là que l'application doit fonctionner correctement car les utilisateurs réels en dépendent. Si l'application génère des erreurs en production, les utilisateurs ne peuvent pas utiliser ses fonctionnalités. Si elle tombe complètement, les utilisateurs ne peuvent pas accéder au service du tout.
La différence entre votre ordinateur et la production
L'écart entre votre ordinateur et un environnement de production est fondamental. Sur votre machine, vous avez un contrôle total et il n'y a pas de conséquences majeures si l'application casse. En production, l'application doit continuer à fonctionner, doit être accessible, et doit rester stable. Les conséquences d'un échec sont directement ressenties par les utilisateurs.
C'est là que de nombreux développeurs réalisent pour la première fois quelque chose d'important : faire fonctionner une application sur son propre ordinateur est une affaire personnelle. Rendre une application utilisable par d'autres personnes est un défi complètement différent. Vous avez besoin d'un endroit pour l'exécuter, d'un moyen de l'y envoyer, et de la certitude qu'elle fonctionnera correctement après son arrivée.
Comment faire parvenir l'application au serveur ?
Une fois que vous avez un serveur, la question naturelle suivante est : comment envoyer l'application là-bas ? Est-il suffisant de copier des fichiers ? Ou y a-t-il plus que cela ?
La réponse dépend du type d'application que vous avez construite. S'il s'agit d'un site web statique simple, copier des fichiers HTML peut fonctionner. Mais la plupart des applications sont plus complexes. Elles ont besoin de dépendances installées, de fichiers de configuration paramétrés, de bases de données connectées, et de variables d'environnement définies. Copier simplement le code est rarement suffisant.
C'est là qu'intervient le concept de déploiement. Le déploiement est le processus qui consiste à prendre votre application depuis sa source — généralement un dépôt de code — et à la faire fonctionner dans un environnement cible. Cela inclut la copie des bons fichiers, l'installation des dépendances, l'exécution des étapes de configuration, et le démarrage du processus applicatif pour qu'il commence à accepter les requêtes.
Un déploiement simple pourrait ressembler à ceci :
- Récupérer le dernier code depuis un dépôt sur le serveur.
- Installer les éventuelles nouvelles dépendances.
- Exécuter les migrations de base de données si le schéma a changé.
- Redémarrer le processus applicatif.
Même cette séquence simple peut mal tourner. Que faire si le serveur exécute un système d'exploitation différent de votre ordinateur ? Que faire si une version de dépendance entre en conflit avec quelque chose déjà installé ? Que faire si la migration de base de données prend plus de temps que prévu et que les utilisateurs voient des erreurs ?
Rendre disponible vs. faire fonctionner
Il y a une autre distinction à noter tôt : placer l'application sur le serveur n'est pas la même chose que la rendre disponible aux utilisateurs.
Vous pouvez copier tous les fichiers sur le serveur, démarrer le processus, et avoir encore une application que personne ne peut atteindre. Peut-être que le pare-feu du serveur bloque le port. Peut-être que le nom de domaine ne pointe pas vers la bonne adresse IP. Peut-être que l'application se lie à localhost au lieu de l'interface réseau. Peut-être que le certificat SSL a expiré et que les navigateurs refusent de se connecter.
Rendre une application vraiment utilisable signifie plus qu'un déploiement. Cela signifie s'assurer que le réseau est configuré correctement, que les enregistrements DNS pointent au bon endroit, que l'application écoute sur la bonne adresse et le bon port, et que le service continue de fonctionner même après un redémarrage du serveur.
C'est pourquoi les environnements de production ne concernent jamais uniquement le code. Ils impliquent la mise en réseau, l'administration système, la surveillance, et souvent une équipe ou une personne distincte responsable du maintien de l'infrastructure en bonne santé.
La suite
Une fois que votre application tourne en production et que les utilisateurs peuvent y accéder, le voyage ne s'arrête pas. Les utilisateurs trouveront des bugs. Ils demanderont de nouvelles fonctionnalités. Quelqu'un découvrira une vulnérabilité de sécurité. L'entreprise voudra ajouter un flux de paiement ou modifier l'interface utilisateur.
Chacun de ces changements signifie que vous devez mettre à jour l'application en production. Et chaque mise à jour comporte des risques. Une nouvelle fonctionnalité peut casser autre chose. Une migration de base de données peut corrompre des données. Un changement de configuration peut ralentir l'application.
C'est là que le besoin d'un processus fiable et reproductible devient évident. Vous ne pouvez pas vous permettre de copier manuellement des fichiers et d'espérer que tout fonctionne à chaque fois que vous faites un changement. Vous avez besoin d'un système qui construit, teste et déploie votre application de manière cohérente.
Ce système est ce que le reste de cette série d'articles explorera. Mais avant d'en arriver là, il vaut la peine de vérifier si votre configuration actuelle couvre les bases.
Un rapide contrôle pratique
Si vous exécutez actuellement une application que d'autres personnes utilisent, posez-vous ces questions :
- Savez-vous exactement quel serveur exécute l'application ?
- Pouvez-vous déployer une nouvelle version en moins de 30 minutes en toute confiance ?
- Si le serveur plante, pouvez-vous restaurer l'application et ses données ?
- Savez-vous ce qui se passe lorsque vous redémarrez le serveur ?
- Pouvez-vous revenir à une version précédente si quelque chose tourne mal ?
Si vous avez répondu "non" à l'une de ces questions, vous n'êtes pas seul. La plupart des équipes commencent avec des processus manuels et s'améliorent avec le temps. L'important est de reconnaître ces lacunes et de commencer à les combler une par une.
Ce qu'il faut retenir
Rendre une application que les gens peuvent vraiment utiliser commence par une vérité simple : votre ordinateur n'est pas la production. L'écart entre l'exécution de code en local et son exécution pour de vrais utilisateurs est là où réside la majeure partie de la complexité de la livraison de logiciels. Avant de vous soucier des pipelines, de l'automatisation ou des stratégies de déploiement avancées, assurez-vous de comprendre où votre application s'exécute, comment elle y arrive, et ce dont elle a besoin pour continuer à fonctionner. Tout le reste se construit sur cette base.