Chez Kinsta, chaque site peut avoir 1 environnement de staging standard et jusqu’à 5 environnements de staging premium. Les environnements de staging vous permettent de tester des extensions, des thèmes ou des modifications de code sans affecter le site en production.

Kinsta offre la possibilité de pousser votre environnement de staging WordPress vers votre environnement de production si vous êtes satisfait des changements que vous avez effectués et que vous souhaitez qu’ils soient appliqués à votre site en production. Et grâce à la fonction de poussée sélective, vous avez un contrôle granulaire sur ce qui doit être poussé en production.

Auparavant, le transfert de l’environnement de staging vers le site en production était un processus tout ou rien, l’environnement de staging écrasant complètement le site en production pendant le transfert. Grâce à la poussée sélective, vous pouvez choisir ce que vous voulez pousser de votre environnement de staging vers votre site en production. Plus précisément, vous pouvez maintenant pousser :

  • Uniquement vos fichiers,
  • Uniquement votre base de données,
  • Ou les deux.

Le passage de la phase de staging vers la production peut se faire en quelques clics, mais veuillez lire les notes ci-dessous avant de procéder. Elles contiennent des informations essentielles sur le processus.

Notes importantes

  • Nous vous recommandons d’utiliser la fonctionnalité « Pouser en production » avec précaution, de la lancer pendant les périodes de faible trafic et d’avoir un développeur à portée de main, au cas où. Si vous avez besoin de l’aide d’un développeur, il existe plusieurs endroits où vous pouvez en engager un.
  • Nous créons automatiquement une sauvegarde pour que vous puissiez revenir en arrière si nécessaire. Remarque : si votre site en production est un site eCommerce ou un autre site dynamique et en évolution rapide, des données peuvent être perdues entre le moment où vous effectuez une poussée et celui où la sauvegarde est restaurée.
  • Les réglages de l’environnement (redirections, géolocalisation, configuration de PHP et de Nginx, etc.) sont inclus dans la poussée transfert (même si l’option Fichiers ou Base de données est sélectionnée) et écraseront complètement les réglages de l’environnement du site de production.
  • Une fois l’opération terminée, videz le cache intégré à votre thème ou à vos extensions, videz le cache de votre navigateur et testez votre site pour vous assurer qu’il fonctionne comme prévu.
  • Lors du transfert de votre base de données, si vous cochez l’option Lancer une recherche et un remplacement, votre domaine de staging sera automatiquement remplacé par le domaine de votre site en production.
  • Toute URL codée en dur dans le code dans votre thème ou vos extensions devra être mise à jour pour correspondre à l’URL du site en production.
  • Si la protection par mot de passe (.htpasswd) est active dans votre environnement de staging, elle ne sera pas transférée à l’environnement de production. Si vous avez besoin de cette configuration sur votre site en production, vous devrez l’activer sur le site de production.
  • Vérifiez à nouveau le site de staging et résolvez toute erreur avant de le pousser en production.
  • Les environnements de staging sont destinés au développement et aux tests uniquement. Ils ne sont pas conçus pour être utilisés comme des sites de production en direct, et il se peut que certaines choses ne fonctionnent pas comme prévu. Kinsta n’est pas responsable si vous essayez d’utiliser un environnement staging pour un site de production.
  • Le passage en production n’affecte pas l’environnement de staging, et il restera séparé du site en production. Après la mise en production, vous pouvez continuer à développer et à tester les changements dans le site de staging sans affecter votre site en production jusqu’à ce que vous poussiez les changements en production.
  • La poussée vers la production n’interfère pas avec Kinsta CDN s’il fonctionne sur votre site en production, mais nous vous recommandons de vider le cache CDN après la poussée (Sites > nom du site > Kinsta CDN > Vider le cache CDN).
  • Poussez vers la production avec prudence si votre site est un réseau multisite. Pousser la base de données peut ou non fonctionner, selon la façon dont le multisite est configuré. Si vous utilisez la poussée sélective et que vous poussez la base de données ou la base de données et les fichiers, le contenu entier de la base de données sera poussé vers la production et affectera tous les sites (le site principal et les sous-sites) de votre réseau multisite.

Comment pousser le staging en production avec la poussée sélective

Suivez les étapes ci-dessous pour pousser votre environnement de staging WordPress vers le site en production. Le flux de travail pour la poussée sélective vous permet de choisir ce que vous allez pousser de votre site de staging vers votre site en production.

Étape 1

Connectez-vous à MyKinsta, cliquez sur Sites, et cliquez sur le site vers lequel vous voulez pousser. Utilisez le sélecteur d’environnement à côté du nom du site pour sélectionner l’environnement de staging depuis lequel vous voulez pousser. Si vous avez ajouté un environnement de staging premium, vous aurez le choix entre plusieurs environnements de staging.

Passer à un environnement de staging WordPress dans MyKinsta.
Passer à un environnement de staging WordPress dans MyKinsta.

Étape 2

Une fois que vous êtes dans l’environnement de staging, cliquez sur le menu Actions d’environnement et sélectionnez Passer en Production depuis le menu déroulant.

Pousser le staging en production dans MyKinsta avec la poussée sélective
Pousser le staging en production dans MyKinsta avec la poussée sélective

Étape 3

Dans la fenêtre pop-up/modale Pousser en production qui s’affiche, choisissez soit Fichiers, soit Base de données, ou cochez les deux, en fonction de ce que vous souhaitez pousser en production. Saisissez le nom du site pour confirmer et cliquez sur le bouton Pousser en production.

Utiliser la poussée sélective pour pousser les fichiers de staging en production.
Utiliser la poussée sélective pour pousser les fichiers de staging en production.

Voici quelques éléments à garder à l’esprit :

  • Le temps nécessaire à la réalisation du processus dépend de la taille de votre site web.
  • MyKinsta vous informera lorsque le processus sera terminé.
  • Votre site web subira un temps d’arrêt de quelques secondes lors des dernières étapes du processus.
  • Les réglages de l’environnement (redirections, géolocalisation, configuration de PHP et de Nginx, etc.) sont inclus dans la poussée transfert (même si l’option Fichiers ou Base de données est sélectionnée) et écraseront complètement les réglages de l’environnement du site de production.

Cas d’utilisation et exemples de flux de travail

Nous avons décrit ci-dessous quelques exemples de cas où vous pourriez vouloir pousser uniquement des fichiers, uniquement la base de données, ou les deux. Gardez à l’esprit les points suivants quand vous transférez le staging vers le site en production :

  • Les réglages de l’environnement (redirections, géolocalisation, configuration de PHP et de Nginx, etc.) sont inclus dans la poussée transfert (même si l’option Fichiers ou Base de données est sélectionnée) et écraseront complètement les réglages de l’environnement du site de production.

Pousser uniquement les fichiers

  • Les modifications apportées directement aux fichiers du thème (notamment HTML, CSS ou PHP) qui n’enregistrent aucune donnée dans la base de données.
  • Téléverser un fichier qui n’a pas besoin d’être inclus dans la médiathèque de WordPress.
  • Si vous avez une extension personnalisée sur votre site et que vous apportez des modifications aux fichiers qui n’affectent pas la base de données (ne sauvegarde pas ou ne modifie pas les données dans la base de données).

Pousser uniquement la base de données

Remarque : Toutes les modifications apportées à la base de données du site en production depuis la création du site de staging seront perdues, y compris, mais sans s’y limiter, les commentaires, le nouveau contenu, les achats sur les sites eCommerce, les inscriptions sur les sites d’adhésion et les messages du forum.

  • Créer ou modifier un nouvel article ou une nouvelle page qui ne contient aucun média téléversé (image, vidéo ou autre fichier téléversé).
  • Modifier la mise en page d’une page ou d’un article par le biais d’une extension de construction.
  • Modifier le titre ou le slogan du site.

Tout pousser

Remarque : Toutes les modifications apportées à la base de données du site en production depuis la création du site de staging seront perdues, y compris, mais sans s’y limiter, les commentaires, le nouveau contenu, les achats sur les sites eCommerce électronique, les inscriptions sur les sites d’adhésion et les messages du forum.

  • Créer un nouveau contenu comprenant des médias téléversés (image, vidéo ou autres fichiers téléversés).
  • Les modifications apportées à votre thème à la fois dans la personnalisation et dans les fichiers du thème.
  • Installer et tester une nouvelle extension ou une version mise à jour d’une extension.

Foire aux questions (FAQ)

Q : Si je teste une extension dans l’environnement de staging et que je ne pousse que les fichiers vers l’environnement de production, cela créera-t-il les tables de base de données correspondantes pour l’extension ?

Si vous installez une extension sur votre site de staging qui n’a jamais été installée sur le site en production, le fait de pousser uniquement les fichiers du site de staging vers le site en production ne créera pas les tables de la base de données pour cette extension.

Cela signifie également que les réglages que vous avez configurés dans l’extension ne seront pas mis en production (sauf si les réglages sont enregistrés dans un fichier hors de la base de données, comme un fichier JSON par exemple).

Selon la façon dont l’extension est codée, l’activation (puis la désactivation si nécessaire) de l’extension sur le site en production peut créer la structure de la base de données.

Q : Si je ne pousse que les fichiers vers la version en production, cela signifie-t-il que l’ancienne base de données (dans le staging) n’écrasera pas la base en production et que seuls les fichiers seront écrasés ?

Oui, lorsque l’on pousse uniquement les fichiers, cela signifie que la base de données du site en direct reste inchangée et que seuls les fichiers du site en production seront écrasés.

Q : Cela signifie-t-il que je peux travailler sur des modifications de conception sur mon site de staging et les pousser en production sans perdre de nouveaux abonnés ou clients sur mon site en production ?

Oui, tant que vos modifications sont apportées uniquement aux fichiers (pas de modifications dans le tableau de bord de WordPress – y compris les réglages des extensions, des thèmes ou de la personnalisation), vous pouvez les pousser en production en toute sécurité sans mettre en production la base de données. Lorsque vous transférez les modifications, sélectionnez Fichiers et assurez-vous que Base de données n’est pas sélectionné.

Q : Puis-je utiliser la fonction de poussée sélective pour modifier la version PHP de mon site ?

Oui, vous pouvez utiliser le staging pour tester et pousser une nouvelle version de PHP vers votre environnement de production, mais il n’est pas strictement nécessaire de pousser depuis le staging vers la production pour mettre à jour votre version de PHP. Voici une vue globale de la façon dont vous pouvez changer la version de PHP sans pousser le staging en production :

  1. Créez un site de staging.
  2. Allez sur le site de staging et changez la version de PHP sur le site de staging.
  3. Si tout est en ordre et fonctionne comme prévu sur le site de staging (veillez à tester votre site de manière approfondie), changez la version de PHP sur le site en production.

Q : J’ai fait des changements CSS dans le tableau de bord de WordPress et j’ai poussé les fichiers. Pourquoi est-ce que je ne vois pas mes changements, même après avoir vidé tout le cache ?

En fonction du type de changement effectué et de l’endroit où ces informations sont stockées, vous devrez peut-être pousser la base de données ou effectuer ces changements manuellement sur le site de production. Par exemple, si vous ajoutez ou modifiez le CSS d’un bloc ou d’un widget dans le tableau de bord de WordPress, cela sera probablement enregistré dans la base de données.

Si vous apportez des modifications à quelque chose dans le tableau de bord de WordPress, à l’exception des modifications effectuées avec l’éditeur de thème (Apparence > Éditeur de thème), ces informations sont généralement stockées dans la base de données.

Remarque : Toute modification apportée à la base de données du site de production depuis la création du site de staging sera perdue, y compris, mais sans s’y limiter, les commentaires, le nouveau contenu, les achats sur les sites d’eCommerce, les inscriptions sur les sites d’adhésion et les messages du forum. Dans ce cas, nous recommandons d’effectuer les mêmes modifications manuellement sur le site de production plutôt que de pousser la base de données.

Q : Comment la poussée sélective fonctionne-t-elle avec un réseau multisite ?

Si vous utilisez la poussée sélective pour pousser uniquement les fichiers, cela fonctionnera bien, quel que soit le type de réseau multisite. Si vous poussez uniquement la base de données ou la base de données et les fichiers, cela peut ou non fonctionner, en fonction de la façon dont votre multisite est configuré :

  • S’il s’agit d’un multisite à sous-répertoire (exemple.com, exemple.com/subsite1, exemple.com/subsite2), le poussée en production fonctionnera comme prévu.
  • S’il s’agit d’un multisite de sous-domaine (exemple.com, sous-site1.exemple.com, sous-site2.exemple.com), il fonctionnera correctement, à condition que les sous-sites ne nécessitent pas de HTTPS.
  • S’il s’agit d’un multisite à mappage de domaines (charge différents sous-sites sur des domaines complètement différents, par exemple exemple exemple.com, exemple1.com, exemple2.com), il ne fonctionnera pas sans une configuration manuelle importante.