Si vous imaginez un diagramme de Venn, les environnements de staging de Kinsta convergeraient à la fois avec le développement pour WordPress et votre cycle de vie DevOps choisi. Ils peuvent faire partie de votre flux de travail depuis la planification initiale jusqu’à la phase opérationnelle. Cela inclut le travail local avec WordPress, l’utilisation du contrôle de version, et presque toutes les autres tâches que vous avez au cours d’un cycle.
Dans cet article, nous allons nous pencher sur le développement de sites dans les environnements de staging de Kinsta. Tout au long de l’article, nous ferons le lien avec un cycle de vie DevOps typique. Il y a beaucoup à faire, alors commençons par les raisons pour lesquelles nous pensons que vous devriez utiliser les environnements de staging proposés par Kinsta.
Les avantages de l’utilisation des environnements de staging de Kinsta
Les environnements de staging de Kinsta vous offrent polyvalence et flexibilité lorsqu’il s’agit de développer des sites web et de les tester. Ces environnements vous permettent de construire dans un cadre qui reflète votre environnement réel. Étant donné que votre serveur live se trouve également sur Kinsta, il s’agit d’un terrain d’essai fiable et précis pour travailler.
Bien sûr, vous pouvez créer, gérer, cloner et supprimer des environnements de staging via le tableau de bord MyKinsta:
Si vous avez besoin de plus de flexibilité, l’extension d’environnement de staging premium vous offre cinq environnements supplémentaires. En outre, vous bénéficierez de notre infrastructure robuste, qui comprend le Premium Tier Network de Google et l’intégration de Cloudflare.
Comme vous pouvez vous y attendre, cela s’accompagne également d’une plus grande puissance sous le capot. En fonction de votre plan, vous obtenez jusqu’à 12 CPU et 8 Go de mémoire, un nombre de workers PHP adapté à votre site live, et la possibilité d’activer le CDN Kinsta pour des performances accrues. C’est une configuration qui convient à un large éventail de tâches, telles que les tests A/B, les vérifications de compatibilité des extensions, les tests gourmands en ressources, et bien plus encore.
Pour le développement local, DevKinsta complète l’ensemble de l’expérience. Une fois que vous êtes sorti de vos phases initiales, vous pouvez pousser votre site directement vers les environnements de staging de Kinsta.
Dans l’ensemble, vous pouvez créer, construire, concevoir, tester et déboguer dans l’écosystème de Kinsta. De plus, il est adapté à votre cycle de vie DevOps. Nous en parlerons plus en détail bientôt. Cependant, nous allons d’abord vous donner quelques informations supplémentaires sur les environnements de staging de Kinsta.
Quelques informations sur les environnements de staging de Kinsta
Les environnements de staging de Kinsta sont excellents lorsqu’il s’agit de tester un site sur un serveur vivant – bien que non productif. Cependant, il y a quelques différences entre l’environnement de staging et l’environnement de production de Kinsta que vous devez connaitre :
- Tout d’abord, nous désactivons par défaut la mise en cache intégrale des pages et OPcache. Vous pouvez les activer si vous le souhaitez, mais sans cela, vous verrez probablement des temps de chargement de page plus élevés.
- De la même manière, l’indexation du site est également désactivée dans WordPress. Bien que vous puissiez le réactiver si nécessaire, un aspect que vous ne pouvez pas désactiver est notre en-tête restrictif d’indexation d’URL temporaire.
- Les tâches cron ne s’exécuteront pas non plus pendant la phase de staging, bien qu’elles soient toujours « en place » Cela signifie que vous pouvez y apporter des modifications, qui remplaceront les tâches cron sur votre site en ligne une fois que vous l’aurez mis en ligne. Pendant que vous êtes dans la phase de staging, cependant, elles ne s’exécuteront pas.
- Notez également que vos identifiants de connexion WordPress seront les mêmes pour votre site de staging que pour votre site en ligne.
Il y a un autre aspect sur lequel nous voulons nous concentrer rapidement avant de passer au flux de travail : la façon dont les extensions interagissent avec le staging.
Utiliser des plugins dans les environnements de staging de Kinsta
Kinsta interdit déjà l’installation de certaines extensions dans WordPress pour des raisons de sécurité et de performance. Cependant, lorsqu’il s’agit du staging, vous voudrez également désactiver certaines des extensions de votre site.
Il y a trois situations dans lesquelles vous voudrez envisager cela :
- Si la licence de votre extension est liée à votre nom de domaine, il se peut qu’elle ne fonctionne pas dans votre environnement de staging.
- Les extensions telles que Jetpack basculent automatiquement en mode « staging ». Il se peut que vous ne voyiez aucune différence, bien qu’aucune des données que vous traitez n’aille sur WordPress.com. Vous ne pourrez pas non plus désactiver Jetpack dans l’environnement de staging.
- Certaines extensions se connectent et publient sur les réseaux sociaux, comme CoSchedule. Dans ce cas, nous vous recommandons de les désactiver jusqu’à ce que vous passiez en production. En effet, elles peuvent planifier et publier des URL à partir de votre environnement de staging.
Vous trouverez de plus amples informations à ce sujet (et bien d’autres) dans notre documentation. C’est une lecture essentielle si vous voulez utiliser les environnements de staging de Kinsta tout en minimisant les effets liés à vos extensions et thèmes.
Un flux de travail de développement typique utilisant les environnements de staging de Kinsta
Vous avez probablement déjà un flux de travail typique pour le développement. En utilisant les environnements de staging de Kinsta, vous pouvez intégrer votre cycle de vie DevOps pour l’intégration continue/déploiement continu (CI/CD) d’une manière transparente.
En fait, le processus commence par un environnement local de développement. Le processus d’installation ne prend pas de temps et gère également la construction d’une base de données MariaDB.
DevKinsta est également idéal pour les projets WordPress headless. Bien qu’ici WordPress s’apparente à une interface de programmation d’application (API) de contenu, vous pouvez toujours construire le frontend à l’aide d’un framework JavaScript tel que React ou Vue.js.
Lorsqu’il est temps de pousser vers le staging, DevKinsta s’occupera du backend de la manière habituelle. Pour le frontend, vous pourrez déployer sur l’hébergement de site statique de Kinsta ou sur notre hébergement d’application.
Voici à quoi peut ressembler le reste d’un flux de travail typique :
- Pousser vers l’environnement de staging. Une fois que vous avez terminé votre développement local et vos tests préliminaires, vous voudrez pousser vers l’environnement de staging. Cette réplique de la production permet de s’assurer que vos tests produisent des résultats similaires à ceux de votre site réel. Il s’agit d’une étape cruciale dans votre pipeline CI/CD, car vous pouvez mettre en œuvre des tests automatisés et une assurance qualité avant le déploiement.
- Tests et débogage. Vous voudrez effectuer plus de tests dans le staging, comme les tests de performance, les analyses de sécurité et les tests d’acceptation par l’utilisateur (UAT). Parce que Kinsta isole les environnements staging et live, ces tests n’auront pas d’impact sur le site live. En utilisant les outils de journalisation, et de surveillance des performances des applications (APM) de Kinsta, vous pouvez également déboguer tout problème ici.
- Intégration et déploiement continus. Après la phase de test et les approbations finales, vous devrez intégrer tous les changements de la phase de préparation dans l’environnement réel. Vous pouvez automatiser certains aspects de ce processus en fonction de votre flux de travail CD/CI. Ainsi, votre contrôle de version central peut rester à jour et vous pouvez déployer le code en production avec un minimum d’intervention.
- Suivi et retour d’information. Après le déploiement, il est crucial d’identifier et de rectifier tout problème à l’aide d’un retour d’information continu et d’une boucle de surveillance. L’APM de Kinsta peut vous aider à relever tous les défis post-déploiement. À partir de là, vous pouvez procéder à une amélioration continue grâce aux informations et aux données que vous recueillez.
Dans l’ensemble, les environnements de staging de Kinsta (et DevKinsta) fournissent une infrastructure robuste pour aider à rationaliser votre flux de développement. Ils prennent même en charge les applications WordPress headless. Dans la section suivante, nous verrons comment vous pouvez utiliser vos compétences DevOps existantes avec nos environnements de staging.
Appliquer les techniques DevOps lors de l’utilisation des environnements de staging de Kinsta
L’application des techniques DevOps dans les environnements de staging de Kinsta peut considérablement améliorer la collaboration et rationaliser le cycle de vie du développement. C’est particulièrement vrai pour les équipes inter-fonctionnelles, car le staging reproduit la production aussi fidèlement que possible.
Cela permet aux développeurs, aux équipes d’assurance qualité (QA) et à d’autres de travailler ensemble de manière synchronisée tout au long des phases de construction, de test et de déploiement. Comme cela se produit dans un environnement contrôlé et isolé, cela permet de minimiser les conflits. Cela vous permet également d’identifier et de résoudre tout problème dès le début du processus de développement.
Au fond, DevOps cherche à supprimer les barrières entre les équipes typiques et traditionnelles « en silo », le développement et les opérations. Les pratiques que vous mettez en œuvre encouragent une culture collaborative, automatisée et intégrative.
De plus, les bonnes pratiques DevOps visent à améliorer la vitesse, l’efficacité et la sécurité de votre développement et de votre déploiement.
Vous pouvez voir cela en action à travers les différentes étapes du cycle de vie DevOps. Il en existe cinq à sept, en fonction de votre projet et de votre équipe :
- Développement. Cette étape implique la planification et le codage, ainsi que le choix de votre environnement de staging. Vous écrirez le code, le testerez et en contrôlerez les versions (probablement à l’aide de Git) avant de passer à l’étape suivante.
- Intégration. C’est ici que vous fusionnerez les modifications de code dans un dépôt central et que vous vous assurerez que ces nouveaux ajouts n’endommagent pas votre site.
- Test. Vous allez ensuite automatiser les tests pour qu’ils s’exécutent dans l’environnement de staging. Vous disposerez ainsi d’une deuxième couche pour garantir un code de qualité et exempt de bogues.
- Déploiement. Après avoir validé le code de l’environnement de staging, vous pouvez automatiser le déploiement dans l’environnement de production. Cela permet de s’assurer que votre site fonctionnera toujours avec la dernière version.
- Surveillance. Après le déploiement, vous voudrez surveiller les performances du site. C’est là qu’un système et un processus d’alerte robustes vous seront utiles. Les données que vous recueillerez ici vous aideront également à fournir des services à l’avenir.
- Retour d’information. Il s’agit d’une phase postérieure au déploiement au cours de laquelle vous recueillez des informations et des données auprès des utilisateurs – dans ce cas, les visiteurs du site. Vous utiliserez le retour d’information de cette étape pour identifier les domaines à améliorer dans le prochain cycle de développement.
- Opérations. Au cours de cette phase, vous serez probablement amené à croiser un nouveau cycle. C’est à ce stade que vous minimisez les pannes, travaillez à l’amélioration du temps de fonctionnement et optimisez la configuration des serveurs.
Selon le nombre d’étapes de votre propre cycle de vie, certaines d’entre elles se dérouleront dans un ordre différent. Par exemple, votre phase d’intégration peut faire partie de vos phases de développement ou de test. En outre, il se peut que certaines de ces étapes n’existent pas, comme une phase de retour d’information ou d’exploitation dédiée.
Les environnements de staging de Kinsta font partie intégrante de la phase de développement, car ils fournissent une zone sécurisée et isolée pour le codage, les tests et le pré-déploiement de l’assurance qualité. L’intégration de ces environnements dans le cycle de vie DevOps peut faciliter votre collaboration, accélérer les délais de livraison et améliorer la qualité de vos livrables.
Ensuite, nous allons vous montrer comment les créer à travers le tableau de bord MyKinsta.
Comment configurer un environnement de staging sur Kinsta
Tous les hébergeurs n’offrent pas cette fonctionnalité, mais les environnements de staging de Kinsta sont disponibles pour tous les plans que nous proposons. L’ensemble du processus ne prend que quelques minutes et un minimum de clics.
De plus, nous n’avons pas besoin de couvrir toutes les étapes ici, car vous pouvez les trouver dans notre base de connaissances. Cependant, en bref, vous pouvez commencer l’installation à partir de votre tableau de bord MyKinsta :
Votre première décision sera de choisir un environnement de staging standard ou premium. Nous vous conseillons de comprendre à quel point l’environnement de staging sera vital pour votre site en production. Par exemple, un environnement standard vous conviendra probablement si vous avez seulement besoin de tester des éléments loin de la production.
En revanche, un environnement premium sera nécessaire si vous avez besoin du même niveau et de la même étendue de ressources que votre site réel. Il existe également d’autres avantages, tels que la possibilité de créer plusieurs environnements de staging. Toutefois, pour les sites à forte intensité de ressources (tels que les boutiques de commerce électronique), vous devrez disposer de ressources équivalentes à celles de votre site en ligne.
Dans la plupart des cas, vous voudrez probablement cloner votre site existant, ce qui est l’une des options dont vous disposez après avoir choisi votre type d’environnement de staging.
En venant de DevKinsta, vous pouvez créer un environnement vierge ici. Il y a un bouton dans les réglages de votre site dans DevKinsta pour passer à l’environnement de staging. Quoi qu’il en soit, vous devrez attendre quelques minutes pour que votre environnement soit complètement configuré. À partir de là, vous pouvez commencer à utiliser vos environnements de staging Kinsta pour construire et tester votre site.
Donner à votre environnement de staging Kinsta une adresse de sous-domaine appropriée
Dans des circonstances normales, votre environnement de staging Kinsta se trouve dans un sous-dossier de votre serveur. Il aura une URL qui est un sous-domaine de kinsta.cloud, mais cela peut causer quelques problèmes :
- Certaines extensions ne fonctionneront pas, comme celles qui ont besoin de vérifier une licence par le biais d’un nom de domaine spécifique.
- Certaines configurations de WordPress Multisite rencontrent des problèmes avec les sous-répertoires sur Kinsta ou nécessitent un sous-domaine personnalisé pour fonctionner de manière optimale.
C’est donc une bonne idée de mettre en place une adresse de sous-domaine appropriée pour vos environnements de staging Kinsta. Pour les utilisateurs premium, Kinsta fournit des adresses de sous-domaines dédiés, mais même cela peut ne pas résoudre vos problèmes.
La solution consiste à configurer un domaine personnalisé pour votre site, puis à exécuter le staging à partir d’un sous-domaine en utilisant le système de noms de domaine (DNS). Une URL de préparation personnalisée utilisant un domaine et un sous-domaine appropriés présente deux avantages : premièrement, vous pouvez atténuer tous les problèmes dont nous avons parlé. Deuxièmement, vous disposez d’un sous-domaine plus agréable à partager avec vos collaborateurs ou vos clients.
Pousser un site en ligne vers l’environnement de staging
L’un des aspects de votre environnement de staging qui peut ne pas être clair au début est la manière d’y transférer votre site réel après l’avoir configuré. Une fois que vous avez compris qu’un environnement de staging est simplement une copie de votre site en ligne, il est plus facile de le visualiser.
Cependant, voici un aperçu rapide du flux de travail pour éviter tout doute :
- Lorsque vous créez un environnement de staging, il s’agit essentiellement d’une copie de votre site réel dans un sous-domaine. Cela inclut toutes vos bases de données et tous vos fichiers. Il s’agit d’une réplique complète, à l’identique, de votre site en ligne.
- Vous apportez des modifications à l’environnement de staging conformément à votre cycle de vie DevOps. Ce cycle est subjectif et dépend de votre projet, de votre flux de travail et de vos objectifs.
- Lorsqu’il s’agit de mettre en ligne ces modifications, plusieurs options s’offrent à vous. Vous pouvez utiliser la fonctionnalité Pousser vers la production intégrée à Kinsta ou effectuer des modifications manuelles. Nous reviendrons sur ce point plus en détail ultérieurement.
- À partir de là, vous disposerez d’une réplique exacte de votre site, tant pour les environnements de staging que pour les environnements réels.
En tant que tel, il n’y a aucun moyen de rafraichir votre environnement de staging en fonction de l’état de votre site réel. Nous vous recommandons de supprimer votre environnement de staging et de le reconstruire lorsque vous en aurez besoin, afin de copier votre site actuel. C’est une autre bonne raison d’utiliser une adresse de sous-domaine personnalisée pour vos environnements de staging Kinsta.
Kinsta fait des sauvegardes à la fois pour votre site en ligne et pour l’environnement de staging. Cela signifie que vous pouvez également restaurer une sauvegarde de votre site en production directement dans l’environnement de staging. Cela vous permet de passer plus facilement d’une phase du cycle de vie à l’autre et d’utiliser des permutations antérieures de votre site pendant le développement.
Notez que vous devrez d’abord configurer votre environnement de staging, mais vous pouvez restaurer votre site dans un environnement standard ou premium. Quoi qu’il en soit, vous pouvez le faire via le tableau de bord MyKinsta :
Cela ne prend que quelques clics et conservera les sauvegardes existantes pour vos sites live et staging, ainsi que tous les domaines personnalisés que vous avez mis en place.
Incorporer le contrôle de version dans votre configuration de staging
De nombreux développeurs utilisent le contrôle de version, tel que Git, que nous recommandons. Les environnements live et staging sur Kinsta offrent une intégration avec Git, ce qui signifie que vous pouvez contrôler les versions de votre site de staging afin de rester en phase avec votre calendrier de développement.
Tirer et cloner un dépôt sur le serveur de Kinsta devrait être un jeu d’enfant. Le processus comporte quelques étapes de base :
- Connectez-vous à votre site en utilisant Secure Shell (SSH).
- Poussez votre version actuelle depuis GitHub, GitLab ou un autre service similaire.
- Vous pouvez également cloner votre dépôt à partir de votre emplacement distant.
La manière dont vous récupérez votre répertoire distant sera différente selon qu’il est public, privé ou qu’il dispose d’une authentification à deux facteurs (2FA). Lorsqu’il s’agit de pousser votre code vers le dépôt, vous devrez trouver un flux de travail approprié.
En effet, les environnements de staging de Kinsta et l’intégration de Git ne prennent pas encore en charge une commande telle que git push kinsta mysite. Néanmoins, il existe des solutions de contournement. Par exemple, vous pouvez utiliser un outil tel que WP Pusher:
Des développeurs astucieux trouvent des moyens uniques de pousser vers GitHub depuis Kinsta, même s’il s’agit d’exécuter une simple commande à partir d’un client Git ou d’automatiser le processus à l’aide de scripts. Nous reviendrons plus tard sur le concept général de pousser votre code vers le site en production.
Effectuer des tests de performance sur les environnements de staging de Kinsta
Une partie de vos phases de test et de surveillance du cycle de vie comprend l’examen (et la comparaison) de la performance de votre site de staging avec des points de référence. La bonne nouvelle, c’est que vous avez accès à tous les outils de Kinsta pour votre site de staging, ainsi que pour le site réel.
En bref, vous récupèrerez des benchmarks pour votre site live, créerez des objectifs que vous aimeriez atteindre et optimiserez votre code au sein de votre site de staging. À partir de là, vous évaluerez si ces changements font une différence positive. Si c’est le cas, vous pouvez aller de l’avant. Si ce n’est pas le cas, vous recommencez les étapes de codage et de test.
Pour les environnements de staging de Kinsta, l’outil APM de Kinsta sera probablement une référence centrale :
Il s’agit d’un outil personnalisé qui se concentre sur les problèmes de WordPress et qui horodate toutes les activités qu’il collecte. Vous pouvez surveiller les processus PHP, vos appels HTTP, les requêtes de base de données, et bien plus encore. Par exemple, nous constatons que la majorité des problèmes de dégradation des performances sont liés à une extension ou à un thème non optimal. Kinsta APM peut vous montrer cela en détail dans l’onglet WordPress.
Vous verrez qu’il est possible d’examiner en profondeur les transactions individuelles, ce qui signifie que vous pouvez voir précisément où se trouvent vos goulots d’étranglement. Pour les sites de staging, vous ne surveillerez pas souvent le temps de transaction Redis. Les temps de PHP et de MySQL seront plus intéressants.
L’utilisation d’un délai absolu lors du dépannage vous aidera à mettre le doigt sur les problèmes. La documentation de Kinsta vous explique le processus général, mais en résumé, les pages qui se chargent lentement doivent être votre première préoccupation.
À partir de là, vous pouvez creuser dans les processus qui composent ces transactions et déraciner le code sous-optimal ou les outils tiers médiocres. Vous utiliserez probablement une combinaison d’outils pour chasser et combattre le code problématique. Pour le développement de WordPress, WP_DEBUG et Query Monitor sont typiques.
Déploiement continu : synchronisation des modifications entre la phase de staging et la phase de production
La phase de déploiement de votre cycle de vie signifie que vous aurez une décision à prendre : quel code pousser. Votre première pensée pourrait être de tout pousser en même temps, mais ce n’est pas toujours la meilleure idée.
En effet, quelle que soit la similitude de vos environnements de staging et de production, ils présenteront toujours des différences. Une approche mesurée peut être plus judicieuse, car vous pouvez pousser une suite de code pour une amélioration spécifique, surveiller les changements, puis programmer la prochaine poussée.
Ce concept est au cœur du déploiement continu, car la sécurité du déploiement doit être une préoccupation majeure. Dans le passé, la fonctionnalité push-to-live de Kinsta, accessible en un clic, renvoyait l’intégralité de votre site sur votre serveur live, quelles que soient les modifications apportées. Cependant, vous avez maintenant aussi des options de poussée sélective : soit en poussant vos fichiers, votre base de données, ou les deux vers le serveur de production :
Même ainsi, cela inclut vos réglages d’environnement, tels que vos configurations Nginx, PHP, et de redirection. Cela peut s’avérer excessif, surtout si vous n’apportez que des modifications mineures à une partie spécifique de votre site.
Bien sûr, vous avez également la possibilité de renoncer aux options de poussée en production de Kinsta et d’effectuer le travail vous-même. L’approche la plus sure consiste à reproduire vos modifications sur le site réel plutôt que de les automatiser. Certes, la mise en œuvre sera plus longue, mais vous aurez la possibilité de contrôler chaque modification au fur et à mesure de sa mise en ligne.
Cependant, quelle que soit votre approche du déploiement continu, vos sauvegardes seront un élément vital. Kinsta effectue des sauvegardes tous les jours pour chaque site de votre compte. Cela inclut les sauvegardes générées par le système ainsi que vos sauvegardes manuelles.
De plus, chaque sauvegarde est un instantané complet d’un environnement spécifique. Cela signifie que vous pouvez revenir à une configuration fonctionnelle connue en quelques minutes si vous devez réparer un site défectueux.
Résumé
Les environnements de staging de Kinsta peuvent vous aider à créer, tester et déployer votre site en production, quel que soit le nombre de phases que vous exécutez ou la nature de chaque étape de votre flux de travail. Ce sont des bêtes flexibles, car vous pouvez utiliser l’environnement de staging gratuit standard sur chaque site que vous exécutez avec Kinsta.
Cependant, avec un environnement de staging premium, vous pouvez mettre en place plusieurs instances, exécuter des ressources qui correspondent à votre site réel, et plus encore. Les environnements de staging de Kinsta sont également excellents lorsqu’ils sont utilisés avec notre hébergement d’applications. Quoi qu’il en soit, vous pouvez faire passer votre site de l’environnement local à l’environnement réel et profiter de l’accès à tous les outils typiques de Kinsta directement à partir du tableau de bord MyKinsta.
Avez-vous des questions sur l’utilisation des environnements de staging de Kinsta en plus de vos techniques DevOps habituelles ? Faites-nous part de vos réflexions dans la section des commentaires ci-dessous !
Laisser un commentaire