Skip to content

Mettre en place un nouveau projet

Un nopCommerce vierge n'est pas encore un projet Spektrum. Il lui manque trois choses : une gestion de la configuration propre à chaque environnement, du monitoring, et une base de données. Cette page décrit comment on comble ces manques. C'est aussi la check-list mentale quand tu reprends un vieux projet et que tu te demandes "est-ce que tout est en place ?".

La configuration par environnement

C'est le point le plus important, et celui qui pose le plus de problèmes quand il est mal compris. nopCommerce charge ses réglages depuis des fichiers appsettings, dans App_Data, et il les empile dans cet ordre :

  1. appsettings.json : la base, toujours chargée.
  2. appsettings.<Environnement>.json : selon la valeur de ASPNETCORE_ENVIRONMENT (Development, Staging ou Production).
  3. appsettings.local.json : le dernier mot, pour les réglages purement personnels.

La règle qui découle de cet empilement, et qu'il faut avoir en tête à chaque fois :

FichierCommitté ?Ce qu'on y met
appsettings.jsonOuiToutes les clés du projet, mais avec des valeurs bidon (API_KEY = XXX). Il sert de référence de structure.
appsettings.Development.jsonOuiLes réglages de dev partagés par toute l'équipe.
appsettings.Staging.json / appsettings.Production.jsonNonLes vraies valeurs des serveurs, posées à la main dessus.
appsettings.local.jsonNonTes réglages à toi (ta base locale, une API qui tourne sur ton poste).

Le piège du appsettings.json réécrasé

Le appsettings.json est redéployé et écrasé à chaque déploiement. N'y mets donc jamais une vraie valeur de production : elle serait soit perdue, soit, pire, exposée dans le dépôt. Les secrets vont dans les fichiers d'environnement posés sur le serveur, jamais dans ce qui est committé.

Pour que le appsettings.local.json soit pris en compte, il faut l'enregistrer comme source de configuration au démarrage de l'application, et surtout l'ajouter au .gitignore (avec ses cousins staging et production) pour que personne ne les committe par accident.

Le monitoring des erreurs

On branche Sentry pour être prévenus quand une boutique tombe en erreur en staging ou en production. Le principe : le package Sentry est ajouté au projet, et on ne l'active que dans les environnements Staging et Production (inutile de polluer Sentry avec les erreurs de ton poste). L'URL du projet Sentry (le DSN) est lue depuis la configuration, donc elle vit dans les appsettings du serveur, pas dans le code.

Dans le même esprit, vérifie que les logs stdout sont activés dans le web.config : c'est ce qui te sauve quand une appli ne démarre même pas et que Sentry n'a rien pu capturer.

La base de données

Deux cas de figure.

Tu pars de zéro. Crée une base vide, pointe ta configuration locale dessus, et lance le site. nopCommerce détecte qu'il n'est pas installé et t'affiche son assistant graphique, qui construit tout le schéma. Rien d'autre à faire.

Tu reprends une base existante (reprise d'un ancien shop, copie de la prod). Tu restaures un dump sur le serveur cible, voir Bases de données pour la mécanique des dumps.

Le "Too many redirects" après un import

À chaque fois qu'on copie une base d'un environnement à un autre, il faut corriger la table Store : la colonne Url doit correspondre à l'URL réelle du site cible, et SslEnabled au fait qu'on force le HTTPS ou non. Si tu oublies, le site part en boucle de redirection infinie (Too many redirects) et tu vas chercher le problème pendant une heure côté serveur web alors qu'il est dans la base. C'est l'erreur numéro un.

Avant une mise en production, si la base a servi à des tests (commandes passées, paniers, cartes cadeaux), il faut la nettoyer : on vide les tables transactionnelles et on remet les compteurs à zéro. Le script est toujours le même.

Script SQL de nettoyage avant prod
sql
DELETE FROM BackInStockSubscription;
DELETE FROM DiscountUsageHistory;
DELETE FROM GiftCardUsageHistory;
DELETE FROM ShoppingCartItem;
DELETE FROM ShipmentItem;
DELETE FROM OrderItem;
DELETE FROM GiftCard;
DELETE FROM Shipment;
DELETE FROM [Order];
DELETE FROM OrderNote;
DELETE FROM ReturnRequest;
DELETE FROM RewardPointsHistory;

DBCC CHECKIDENT (BackInStockSubscription, RESEED, 0)
DBCC CHECKIDENT (DiscountUsageHistory, RESEED, 0)
DBCC CHECKIDENT (GiftCardUsageHistory, RESEED, 0)
DBCC CHECKIDENT (ShoppingCartItem, RESEED, 0)
DBCC CHECKIDENT (ShipmentItem, RESEED, 0)
DBCC CHECKIDENT (OrderItem, RESEED, 0)
DBCC CHECKIDENT (GiftCard, RESEED, 0)
DBCC CHECKIDENT (Shipment, RESEED, 0)
DBCC CHECKIDENT ([Order], RESEED, 0)
DBCC CHECKIDENT (OrderNote, RESEED, 0)
DBCC CHECKIDENT (ReturnRequest, RESEED, 0)
DBCC CHECKIDENT (RewardPointsHistory, RESEED, 0)

Une fois nettoyé, revérifie les quantités en stock et refais l'import des clients : le nettoyage ne touche pas au catalogue ni aux comptes, mais c'est le bon moment pour s'assurer que tout est cohérent.

Reprendre les membres d'un ancien site

Quand une nouvelle boutique remplace un site Umbraco qui gérait ses propres membres, on récupère ces comptes. La logique est simple, même si elle demande un peu de préparation manuelle : on commence par recréer dans nopCommerce les rôles qui existaient, on exporte les membres depuis Umbraco en Excel, puis on remplace dans le fichier les rôles écrits en toutes lettres par les identifiants des rôles nopCommerce correspondants. Un endpoint d'import maison se charge ensuite de créer les comptes à partir de ce fichier. Après coup, vérifie systématiquement qu'un compte repris arrive bien à se connecter avant d'annoncer quoi que ce soit au client.

Les renvois vers Umbraco

Deux comportements se configurent côté nopCommerce mais regardent vers Umbraco : la page 404 et les liens partagés. Quand le shop ne trouve pas une URL, on préfère renvoyer vers la jolie page 404 du site Umbraco plutôt que celle, austère, de nopCommerce. Il suffit pour ça d'indiquer au shop l'adresse de base du site Umbraco et le chemin de sa page 404. C'est le même genre de réglage que pour le header et le footer, décrits dans Intégration avec Umbraco.

Étape suivante

Une fois la base en place, passe à l'Intégration avec Umbraco.

Contributors

The avatar of contributor named as Clément Favre Clément Favre

Changelog