Table des matières
Proc#144 - Installation et mise à jour des serveurs et des applications
Informations qualité
| Suivi des modifications majeures | ||
|---|---|---|
| Date | Auteur | Modifications |
| 11 août 2016 | Mélanie LOUBET | Création du document |
| 13 décembre 2016 | Valentin BARRÈRE | Mise à jour |
| 1 août 2017 | Nicolas MARCHAND | Portage sur le wiki |
| 12 septembre 2017 | Valentin BARRÈRE | Mise à jour : nouvelle procédure |
| 10 septembre 2019 | Nicolas MARCHAND | Refonte avec automatisation des process |
| 30 septembre 2026 | Nicolas MARCHAND | Transformation en procédure générique pour tous les composants ; le détail technique est déplacé dans des documents techniques, un par type de composant ; mise au format de la maîtrise documentaire |
| Suivi des approbations | Cartographie fonctionnelle – fiche de la procédure |
| Objet | Définir les règles communes à l'installation et à la mise à jour des serveurs et des applications de la Galaxie LoGeAs, et indiquer le document technique à suivre pour chaque type de composant. |
| Destinataires | - Validation des modifications : Gérant - Approbation du document : Équipe développement |
| Origine | Ce document reprend l'ancien élément ProjeQtOr Document #42 « Procédure de MAJ du serveur PGI », étendu à l'ensemble des composants. |
Périmètre
Cette procédure s'applique à toute installation ou mise à jour d'un composant de la Galaxie LoGeAs sur un serveur de test ou de production.
Elle fixe les règles. Le mode opératoire détaillé de chaque type de composant est dans un document technique (voir Proc#163 pour le statut de ces documents).
| Type de composant | Exemples | Document technique |
|---|---|---|
| Serveurs Delphi (services Windows) | serveur PGI, serveur de bases LoGeAs Web | Document technique — Serveurs Delphi : PGI et LoGeAs Web |
| Application Angular servie par IIS | LoGeAs Web, Assistance, Cartographie fonctionnelle | Document technique — Application Angular (SPA) sur Windows Server + IIS |
| API .NET hébergée par IIS | API des formulaires | Document technique — API .NET (Stimulsoft.PDF.Forms + EF Core SQLite) sur Windows Server + IIS |
| Application Node.js derrière IIS | application de questionnaires | Document technique — Application Node.js sur Windows Server + IIS |
La production de la version à déployer ne relève pas de cette procédure :
- LoGeAs Web : Proc#168 - Chaîne de qualification et de livraison ;
- client lourd : Proc#167 - Mise en ligne d'une version du client « lourd » ;
- règles de numérotation : Proc#145 - Gestion des versions.
Responsabilités
| Action | Qui |
|---|---|
| Décider d'une installation ou d'une mise à jour | Chef de projet |
| Réaliser l'installation ou la mise à jour | Chef de projet |
| Tenir à jour les documents techniques | Équipe développement |
Règles communes
- On ne déploie que des versions livrées. Une version mise en production est une version produite selon sa procédure de livraison (Proc#168 ou Proc#167), identifiée par son numéro et son tag Git.
- On suit le document technique du composant, dans l'ordre de ses étapes. Si le document ne correspond plus à la réalité, on le corrige à l'occasion du déploiement.
- Sauvegarde : elle est automatique. Aucune sauvegarde manuelle n'est à faire avant une mise à jour.
- Secrets : les mots de passe, clés et certificats sont dans Dashlane. Ils ne sont jamais écrits dans le wiki ni dans un document technique.
- Accès au serveur : par le bureau à distance, avec son compte personnel.
Déroulé
- Préparer : vérifier que la version à déployer a bien été livrée (numéro de version, tag Git), puis préparer les fichiers selon le document technique.
- Transférer les fichiers vers le serveur.
- Installer ou mettre à jour selon le document technique.
- Vérifier : le composant répond et affiche le numéro de version attendu.
Documents techniques
Un document technique décrit le « comment » pour un type de composant : outils, chemins, commandes, configuration, dépannage.
- Il est rattaché à la présente procédure, qu'il cite en tête de page.
- Il n'est pas soumis à validation ni à approbation : l'équipe de développement le met à jour dès que la pratique change.
- Il ne peut pas contredire les règles de la présente procédure. Si une règle doit changer, c'est la procédure qui est modifiée, puis validée et approuvée.
L'ajout d'un nouveau type de composant se fait en créant son document technique et en ajoutant une ligne au tableau du périmètre. C'est une modification majeure de la présente procédure.