Check-list de mise en prod

Cette page regroupe les étapes de mise en production / staging d'un site (typiquement Umbraco) ainsi que la check-list des points à ne pas oublier avant et après la mise en ligne.

Cases à cocher persistantes

Coche les tâches au fil de ton déploiement et clique sur le libellé pour déplier le détail. L'état des cases est conservé pendant toute la durée de ta session de navigation (il se réinitialise à la fermeture du navigateur). Le bouton "Réinitialiser" remet la liste à zéro.

Étapes de mise en production / staging

Étapes de déploiement0 / 0

But : faire pointer un nom de domaine ou sous-domaine vers le serveur d'hébergement où sera hébergé le site.

Actuellement nos sites sont hébergés sur la VM Azure Columbia (Linux) => columbia.spektrum.media.

Si le nom de domaine est chez Spektrum (comme les staging en .spektrum.media) :

• Se connecter sur Amazon Route 53 (credentials sur Guardian).
• Ajouter dans la hosted zone spektrum.media une nouvelle entrée (sous-domaine) :
  • Entrer le nom du sous-domaine.
  • Mettre en CNAME le nom de domaine du serveur d'hébergement, ex : columbia.spektrum.media.
  • Laisser 300 comme TTL (ou moins si voulu).

Si le nom de domaine est hébergé ailleurs (ex : Infomaniak) :

• Se connecter sur le service qui héberge le nom de domaine.
• Créer la zone DNS souhaitée et la faire pointer en CNAME vers le serveur d'hébergement, ex : columbia.spektrum.media.

Certains clients, particulièrement les communes, ont un DNS interne dans leur réseau. Si on modifie la zone du domaine de leur site, il se peut que ces changements ne soient pas répercutés chez eux et qu'ils ne voient pas les modifications.

Ce fut le cas pour ACCM, dont la gestion du DNS interne est gérée par PcProfit. À checker dans le fichier "Client - Contact.xlsx" ou directement avec eux si c'est leur cas.

But : répliquer la base de données de développement sur le serveur d'hébergement des DB pour l'utiliser dans l'environnement souhaité (production / staging).

Versions de SQL Server

Pour que les export / import data-tier application fonctionnent correctement dans Management Studio, il faut que tout le monde soit sur la même version majeure (machine locale, serveur d'hébergement de DB, etc.).

• Extraire la DB locale du dev en faisant un Export data-tier application.
• Se connecter sur la VM Azure vmsqla001 où sont hébergées toutes les bases Microsoft SQL (vmsqla001 sur Guardian), soit en RDP, soit directement via Management Studio local.
• Importer la DB via Import data-tier application sur le serveur. La nommer umb_<mon-site>_<prod | staging> (ex : umb_the-swiss-collector_staging, umb = Umbraco).
• Supprimer les anciens users locaux (ex : dev) et ajouter un nouvel user spécifique au client, utilisable pour les DB staging et production. Attention à ne pas mettre d'expiration de mot de passe.
• Créer un item sur Guardian avec le username / password ainsi que la liste des DB associées (staging, prod, etc.).

But : préparer une image Docker custom qui pourra être utilisée par un container.

• À la racine du projet, créer un dossier hosting et y mettre un fichier Dockerfile (contenu fourni dans la tâche source).
• Adapter le fichier au besoin ; par défaut il fonctionne pour un site Umbraco.
• Pusher le fichier sur Git (par exemple sur la branche develop) pour que tout le monde y ait accès.

Le container qui utilisera cette image aura un répertoire /app contenant tout le projet web compilé. Au lancement, le site démarre directement dans le serveur web intégré au framework .NET nommé Kestrel : pas besoin de IIS. Les variables d'environnement (environnement .NET Core, port d'écoute, etc.) seront configurées directement dans le docker-compose.

But : créer et publier l'image Docker du site dans le repository de Spektrum pour qu'elle puisse être utilisée par nos containers.

• Sous Windows, lancer d'abord Docker Desktop.
• Se mettre à la racine du projet.
• Créer l'image en local :

docker build -t columbia-registry.spektrum.media/umb_<mon-site>:<staging | prod> -f hosting/Dockerfile .

• Publier l'image sur le repository de Spektrum :

docker push columbia-registry.spektrum.media/umb_<mon-site>:<staging | prod>

En adaptant <mon-site> et <staging | prod> avec les vraies valeurs. On a maintenant notre image avec le bon tag disponible sur le repository de Spektrum. On le fait une seule fois à la main ; plus tard cette étape sera automatisée par le déploiement continu (CircleCI).

But : avoir un fichier docker-compose prêt à créer le container qui contiendra le site.

• À la racine du projet, dans le dossier hosting, créer un fichier docker-compose.yml (contenu fourni dans la tâche source).
• Adapter le fichier, notamment :
  • Le nom du service en respectant umb_<mon-site>.
  • Le nom de l'image (celle voulue sur le repository Spektrum, dans le bon tag).
  • Le mapping de port sera fait plus tard sur le serveur ; le port interne peut rester 5000.
  • Mapper dans les volumes ce dont le site a besoin, par défaut : le fichier appsettings.json, les médias, les logs Umbraco.
  • Les variables d'environnement :
    • ASPNETCORE_ENVIRONMENT=Staging (ou Production)
    • ASPNETCORE_URLS=http://*:5000 (garder en http et le même port que le port interne choisi)
    • ASPNETCORE_FORWARDEDHEADERS_ENABLED=true (indispensable pour les sites Umbraco : permet de bien recevoir les headers venant de NGINX, dont le protocole et le hostname d'origine, plutôt que le http interne de Docker).
• Pusher le fichier sur Git (par exemple sur develop).

But : créer le container du site sur le serveur d'hébergement (ex : Columbia, Linux) et le lancer.

Commandes en sudo

Les commandes à exécuter sur le serveur sont à faire en sudo.

• Se connecter en SSH sur le serveur d'hébergement (ex : Columbia) avec nos credentials (voir avec Yves).
• Aller dans le dossier /data.
• Créer un dossier umb_<mon-site>_<staging | prod>.
• Dans ce dossier, créer un docker-compose.yml reprenant celui du dossier hosting.
• Créer aussi tout ce qui doit être mappé (voir le docker-compose), souvent :
  • appsettings.json : y mettre déjà toutes les données de production (connexion à la DB prod / staging, clés, Sentry, etc.), au moins la DB.
  • Dossier logs.
  • Dossier media : y mettre les médias présents en dev. Sur WSL Windows, on peut faire sudo scp media.zip azureuser@columbia.spektrum.media:~/ pour envoyer un zip dans le home de Columbia.
  • Dossier dp-keys (clés DataProtection) : monter - ./dp-keys:/root/.aspnet/DataProtection-Keys pour que les clés survivent à la recréation du conteneur (sinon déconnexion du backoffice à chaque redéploiement). Voir Déconnexion du backoffice après un redéploiement.

Portainer : le serveur héberge aussi l'application web Portainer, qui permet d'administrer les containers.

• Aller sur https://columbia-portainer.spektrum.media, sous Containers, pour voir tous les containers qui tournent (inspecter, voir les logs, etc.).
• Repérer le prochain port externe disponible (les apps tournent sur 5000, 5001, 5002, etc.).
• Modifier le docker-compose pour y mettre ce port externe libre, sinon le container ne se lancera pas.
• Créer et lancer le container :

sudo docker compose up -d

Le container doit maintenant tourner et être visible dans Portainer.

But : créer une entrée dans le reverse proxy NGINX pour que l'URL du site pointe correctement sur l'app qui tourne dans le container.

• Se connecter sur l'interface NGINX correspondant à l'environnement :
  • Production : https://nginx.prod.spektrum-suisse.ch/
  • Staging / interne : https://nginx.internal.spektrum-suisse.ch/
• Sous "Proxy Hosts", faire "Add Proxy Host".
• Onglet "Details" :
  • Domain Names : le nom de domaine créé à la première étape (ex : the-swiss-collector.spektrum.media).
  • Scheme : laisser http.
  • Forward Hostname / IP : le nom de notre container.
  • Forward Port : le port interne du container (normalement 5000), et non l'externe.
• Onglet "SSL" :
  • Sélectionner "Request a new certificate with Let's Encrypt".
  • Cocher "Force SSL".
  • Laisser le reste par défaut et accepter les conditions.
• Terminer avec "Save".

Le site est maintenant accessible via son nom de domaine.

But : le site est accessible mais peut faire des erreurs (ex : "Too many redirects"). Certaines choses doivent être mises à jour dans Umbraco car elles ne correspondent plus à l'environnement de dev.

• Aller sur le backoffice Umbraco avec les credentials du développement.
• Modifier :
  • L'user "Spektrum" comme utilisateur Umbraco : mettre l'alias geeks+<mon-site>@spektrummedia.com avec un mot de passe généré (si pas déjà fait).
  • Mettre sur Guardian les infos de connexion au backoffice en précisant l'environnement, avec un mot de passe différent en production.
  • Modifier la culture et noms d'hôte du / des noeuds d'accueil pour mettre le nom de domaine actuel (ex : the-swiss-collector.spektrum.media) et faire les adaptations dans les autres langues. Ne pas mettre le protocole (https), seulement le nom de domaine, sinon cela peut poser problème avec le réseau Docker interne qui communique en http.
  • Faire un uSync import pour être sûr que tout est importé.

Bien mettre les credentials sur Guardian pour que tout le monde y ait accès.

But : mettre en place le déploiement continu avec GitLab CI afin que le site se publie automatiquement dans le bon environnement lors d'un push sur la branche staging ou master. Le CI/CD passe désormais par GitLab (et non plus CircleCI).

• Ajouter à la racine du projet un fichier .gitlab-ci.yml (anciennement .circleci/config.yml).
• Adapter le pipeline, notamment :
  • Les spécificités du build frontend / backend (supprimer la partie tests si non utilisée).
  • La version de l'image Node pour matcher celle utilisée en dev.
  • Les jobs de déploiement : branches master / staging et nom de l'image Docker créée et publiée (le tag dépend de la branche).
• Pusher sur GitLab : le pipeline se déclenche automatiquement à chaque push, sans configuration externe à activer.

Règles de déploiement par branche :

• Merge sur staging => déploiement en staging.
• Merge sur master => déploiement en production (le job de prod doit être confirmé manuellement dans GitLab, bouton "play").

Pour le détail du fonctionnement (build Docker multistage, cache des couches, fichiers .config), voir Sites Spektrum : fonctionnement CI/CD et Mettre à jour un StarterKit.

Check-list avant / après mise en prod

Avant / après mise en prod0 / 0

Mettre à jour les favicons. Utilitaire pour les générer : https://realfavicongenerator.net/.

Mettre à jour l'image OG par défaut du site en 1200x630. Spécifique plutôt à Umbraco : par défaut dans /images/og/default.png.

Mettre à jour l'image visible sur la page de login Umbraco, dans /images/custom-backoffice-login/bg.jpg. Attention à la taille de l'image, bien la tester.

Mettre des canonicals si besoin pour le contenu dupliqué : injecter l'URL de la page originelle dans ViewBag.Canonical et tester que cela fonctionne.

Avoir les MetaTitle / MetaDescription sur les pages à indexer. Pour Umbraco, à mettre directement dans les settings de la page dans le backoffice. On peut aussi les redéfinir en code via ViewBag.MetaTitle et ViewBag.MetaDescription pour des besoins spécifiques.

Ajouter les outils d'analyse, marketing, etc. (analytics). Attention à ne les charger que si les cookies sont acceptés.

Vérifier que les pages 404 et 500 sont configurées, qu'elles apparaissent quand il le faut (tester réellement en provoquant une erreur 500) et qu'elles soient jolies.

Vérifier que le logo Spektrum est en footer et redirige vers notre site.

S'il y en a un, être sûr que le SMTP est bien configuré et que c'est celui du client.

Checker en production les workflows Umbraco Forms : être sûr qu'on envoie l'email à la bonne adresse, faire tester chaque formulaire par le client.

Tester en production chaque fonctionnalité interactive du site, de bout en bout :

• Inscription à la newsletter (réception de l'email, ajout dans l'outil d'envoi).
• Formulaire de contact et autres formulaires (réception côté client, message de confirmation).
• Recherche, filtres, espace membre, paiement, etc. selon le site.

L'environnement de production diffère souvent du dev (clés API, SMTP, comptes réels) : il faut donc retester réellement, idéalement avec le client.

Cacher du sitemap les pages non voulues pour l'indexation, puis tester que le sitemap fonctionne.

Ajouter les ogTitle / description / image si besoin sur certaines pages, et tester.

Ajouter les langues du site si plusieurs langues.

Ajouter / vérifier les clés de dictionnaire (traductions) de toutes les langues.

Mettre en place la popup d'acceptation / refus des cookies.

Utiliser le health check Umbraco : dans le backoffice, aller dans "Configuration" => "Health Check" et checker tous les groupes. Umbraco vérifie si des choses sont mal configurées ou manquantes. Regarder les résultats et appliquer les modifications nécessaires.

Les redirections doivent se faire le plus tôt possible, donc au niveau du reverse proxy (s'il y en a un, ex : Apache) ou directement dans le serveur web (ex : web.config pour IIS).

Outil créé par mattsinge pour générer facilement des règles de redirection (IIS, web.config) d'anciennes URLs vers de nouvelles à partir d'un Excel (souvent préparé par Sam) : https://bitbucket.org/spektrummedia/redirect-rules-creator.

Ordre et type des règles

Attention à l'ordre : les règles sont lues une à une de haut en bas. Toujours mettre en "Temporary" en premier, et en "Permanent" seulement si on sait vraiment ce qu'on fait. Une règle permanente est mise en cache chez chaque client : en cas d'erreur, la seule façon de propager la correction est que le client vide son cache, ce qui est en pratique impossible à faire faire.

Sous-règles classiques (chacune est une case à cocher ci-dessous) : Force HTTPS, Remove www, Remove trailing slash, blocage des user-agents, redirections SEO.

Rediriger tout le trafic http vers https.

Rediriger les URLs avec www vers la version sans www (ou l'inverse selon le choix).

Normaliser les URLs en supprimant le slash final.

Bloquer les user-agents indésirables : bots malveillants, user-agents vides, etc.

Rediriger les anciennes URLs qui retournent un 404 vers les nouvelles URLs correspondantes, pour préserver le SEO.

Tester le robots.txt.

Staging

En version de staging, le site ne doit pas indexer les pages du tout.

Checker le site sur des checkers en ligne, Google Dev Tools, etc.

Tester le responsive du site avec son natel, etc.

Sentry permet de logger les exceptions et anomalies d'un site (staging ou production).

• Se connecter sur https://sentry.io avec son compte ou celui de geeks, ajouter un nouveau projet, récupérer la clé client DSN et la mettre dans l'appsettings du site Umbraco.
• Le même projet / DSN est utilisé pour le staging et la production : Sentry détecte automatiquement l'environnement.
• Configuration du projet :
  • Le mettre dans la team spektrum-suisse pour trier facilement nos projets.
  • Aller dans "Alert settings" => "View Alert Rules", choisir la team spektrum-suisse, puis dupliquer la règle d'un projet suisse existant et l'adapter.

Une fois fini, chaque exception levée déclenche une notification Slack ainsi qu'un mail dans certains cas. (Il est aussi possible de configurer Sentry pour le JavaScript, à voir si cela a du sens.)

Tout site mis en production (ou en staging permanent) doit être surveillé pour qu'on soit alerté s'il tombe avant le client. On utilise désormais Prometheus / Grafana (sonde blackbox qui vérifie que l'URL répond en 200 OK), à la place de l'ancien service Uptime.

Concrètement : ajouter l'URL du site dans la config Prometheus (job website-monitor-prod ou website-monitor-staging), en respectant le tri alphabétique, puis recharger Prometheus.

À faire dans le même PR

Tout nouveau site en prod (ou staging permanent) doit être ajouté au monitoring dans le même PR que sa mise en ligne, sinon on l'oublie.

Procédure détaillée : voir Monitoring Grafana - ajouter un site.

Mettre à jour le README du projet, en incluant au minimum :

• Une description avec les badges GitLab CI de build (staging et prod).
• Les URLs et où sont hébergés les sites (staging / prod).
• Les technologies utilisées.
• Le système de branches / workflow de développement.
• Comment build le projet (frontend, backend, spécificités).
• Où sont hébergées les bases de données (staging et prod) et leurs subtilités.
• Autres infos utiles.

Que chaque image affichée dans le site Umbraco soit optimisée avec ImageSharp :

• Pourcentage de qualité d'image.
• Taille adaptée par type d'écran (balises <picture> et <source>).
• Retina factor.

ZAProxy (https://www.zaproxy.org/) ou des outils du même genre peuvent être utiles pour tester le site et faire ressortir des erreurs.

Vérifier le score du site sur PageSpeed Insights (https://pagespeed.web.dev/) : le client regarde cela et c'est important pour le SEO. En complément : validator.w3.org, yellowlab.tools.

Contributors

Clément Favre

Changelog

Last edited about 2 months ago

View full history

b07d2bb-docs: add Crans-Montana headless and police intranets to parc inventory