Différences

Ci-dessous, les différences entre deux révisions de la page.

--- bloc2:prog:web:deploiement [2023/04/06 16:25] – [choisir un hébergement] admin
+++ bloc2:prog:web:deploiement [2023/04/06 18:43] (Version actuelle) – [Procédure de déploiement d’une application web] admin
@@ Ligne 1: / Ligne 1: @@
-====== Procédure de déploiement d’une application web ======
+====== Déploiement d’une application web ======
 ===== Choisir un nom de domaine =====
 Pour commencer, on pourra consulter cette page de [[https://www.afnic.fr/noms-de-domaine/tout-savoir/|l'Afnic]]
@@ Ligne 22: / Ligne 22: @@
   * **Hébergement mutualisé** : mise à disposition d’un serveur dont les ressources sont partagées par plusieurs clients. Il s’agit d’une entrée de gamme qui convient à des besoins sans exigences fortes ;
   * **Hébergement hybride (VPS)** : mise à disposition d’une machine virtuelle dédiée sur un serveur physique mutualisé. On dispose des possibilités de « sur-mesure » du modèle dédié du fait que l’on est seul utilisateur du serveur virtuel. On demeure, par contre, contraint par les performances et la disponibilité du modèle mutualisé puisque le serveur physique est partagé.
+===== Configurer l’infrastructure d’hébergement =====
+Une fois le contrat d’hébergement activé, selon l’offre retenue, il conviendra éventuellement de configurer l’ensemble des services mis à disposition (serveur web, serveur de base de données, langage hôte, etc.). Cela devra toujours se faire en envisageant par anticipation de possibles évolutions :
+  * Augmentation du **volume** de la base de données ;
+  * Cohabitation sur le même domaine de plusieurs applications distinctes (**multisite**);
+  * **Tenue à jour** des différents composants mis en jeu ;
+  * Possibilités de **sauvegardes** ;
+===== Tester le SGBD =====
+Afin de ne pas mélanger les problèmes, il faudra commencer par vérifier que le SGBD répond bien aux attentes, **indépendamment de l'application** à déployer, en :
+  - Créant une base de données de test contenant au moins deux tables reliées entre-elles ;
+  - Alimentant un jeu d’essai minimal dans les tables ;
+  - Créant un utilisateur disposant des droits essentiels sur la BdD de test ;
+===== Tester le serveur web =====
+Vérifier que le serveur web répond bien à une sollicitation venue de l’extérieur hors de la présence de l’application. Plusieurs étapes progressives peuvent être envisagés :
+  - Affichage d’une page par défaut (type **site en construction**) ;
+  - Affichage d’une page de tests du langage hôte (type page **php_info** de php) ;
+  - Accès à une **base de données** de test ;
+===== Remonter le code de l’application via un client ftp =====
+Utiliser un client FTP (FileZilla ou équivalent) pour uploader le code de l’application au bon endroit dans l’arborescence du serveur WEB.
+On préfèrera réaliser l'opération en utilisant un protocole de chiffrement (**SFTP** par ex.) pour ne pas exposer les communications qui peuvent contenir des informations sensibles.
+===== Mettre en place la base de données =====
+Selon le cas, utiliser l’application elle-même ou un script SQL fourni avec elle pour mettre en place la base de données de production.
+===== Adapter les fichiers de configuration de l’application =====
+Dans de nombreux cas, il faudra envisager d'adapter le paramétrage de l’application, via ses fichiers de configuration, pour qu’elle opère dans les conditions propres à l'hébergement. Typiquement, il pourra s’agir de mettre à jour les informations du compte utilisateur à employer pour accéder à la BdD. Mais, à ce stade, le champ possible des adaptations à réaliser est tellement large qu’il ne sera pas question d’en dresser l’inventaire ici.
+Une très bonne pratique consistera ici à avoir anticipé (presque) toutes les spécificités de la plateforme de production et à les avoir mises en œuvre à l’identique sur la plateforme de développement. De cette manière, il n’y aura (presque) aucune adaptation à réaliser dans la configuration au moment de sa mise en ligne.
+===== Tester l’application =====
+Dès lors, on considèrera que l’application est en ligne dans des conditions lui permettant de subir une phase de **tests fonctionnels** conçus selon la structure des cas d’utilisations. Chaque cas d’utilisation sera testé au moyen d’une série de situations, qu’elles soient nominales ou alternatives (exceptions), la plus large possible (**couverture**).
+===== Référencement =====
+Dans le cas d’une application pour laquelle le référencement est une nécessité, on suppose que le travail en [[https://fr.wikipedia.org/wiki/Optimisation_pour_les_moteurs_de_recherche|SEO]] a été réalisé en amont. Il s’agira donc ici de vérifier **après quelques semaines de fonctionnement** le niveau de qualité de ce référencement.
+===== Cyber sécurité =====
+Toute application mise en ligne s’ouvre à de potentiels actes malveillants. Le développement de l’application aura évidemment dû en tenir compte (voir la [[https://www.sans.org/cloud-security/securing-web-application-technologies/?msc=cloud-security-lp|checklist SWAT]]).
+Pour vérifier la robustesse de l’application, il faudra alors intégrer une séquence de test d’intrusion ([[https://fr.wikipedia.org/wiki/Test_d'intrusion|Pen Testing]]) qui pourra, le cas échéant, laisser apparaitre telle ou telle insuffisance.