Share
Dans cette série, nous examinons les différentes pratiques utilisées dans le développement professionnel de WordPress. Dans l'article précédent, nous avons examiné un ensemble de stratégies et de documents de référence utiles pour la création de thèmes, de plug-ins et d'applications basées sur WordPress..
Dans cet article, nous examinerons les configurations de contrôle de version et d'environnement qui facilitent le développement, le test et le déploiement de notre travail afin de minimiser le nombre d'erreurs qui se retrouvent dans les versions finales de notre travail..
Ce sujet n'est pas nouveau. En fait, je me risquerais à dire que la majorité des lecteurs ici présents connaissent Subversion et / ou Git (en particulier la popularité de GitHub). En tant que tel, le but de cet article n’est pas tant d’expliquer les différents systèmes de contrôle de source, ni d’indiquer ceux que vous devriez utiliser, mais bien d’avoir pour objectif Pourquoi vous devriez utiliser le contrôle de code source et son rapport avec nos environnements.
Si vous êtes complètement Pour la première fois sur le concept de contrôle de version, fournissons une définition simple sur laquelle nous pouvons travailler afin que nous soyons tous sur la même page:
Le contrôle de version est un instantané de votre code source à tout moment qui vous permet de revenir en arrière lorsqu'un bogue est introduit et de travailler sur une nouvelle fonctionnalité sans détruire le code existant..
Au sein de la communauté WordPress, les gens sont souvent divisés sur l'opportunité de considérer des thèmes et / ou des plugins, des logiciels ou des sites Web enrichis. Personnellement, je pense qu’il s’agit d’une forme de logiciel car ils sont soumis à de nombreuses pratiques identiques:
À cette fin, le développement et la maintenance de travaux spécifiques à WordPress doivent être traités comme tels et il est dans la norme de l'industrie de fournir un niveau de contrôle de version sur les logiciels..
De plus, le contrôle de version fonctionne de pair avec le travail sur votre projet, son test, puis son déploiement sur un serveur actif pour que d'autres puissent l'utiliser..
La plupart des développeurs connaissent les différents environnements même s'ils n'utilisent pas la terminologie exacte. Simplement défini:
Assez simple.
Le fait est que chacun de ces environnements est également étroitement lié au contrôle de version, de sorte que, lorsqu'il est géré correctement, vous pouvez réduire les frais généraux liés à la maintenance des versions et des déploiements de votre travail..
L'environnement de développement est la machine sur laquelle vous développez réellement votre projet. Il comprend une copie de WordPress, du serveur Web, du serveur de base de données, de l'EDI et des outils connexes que vous utilisez pour construire votre projet..
C'est dans cet environnement que vous devriez faire des commits fréquents. J'entends par là que chaque fois que vous apportez un changement important, qu'il s'agisse d'une nouvelle fonctionnalité, d'une résolution de bogue ou de quelque chose de similaire, vous devriez alors envoyer du code dans le référentiel..
Ici, l'avantage est que vous pouvez facilement annuler, identifier et distinguer les modifications en cas de problème au cours du processus..
Une fois que vous avez apporté un nombre important de modifications (lorsque vous ou votre équipe déterminez ce qui constitue un élément "significatif"), il est temps de marquer l'ensemble des modifications et de le déployer dans l'environnement de transfert..
L'environnement intermédiaire est un serveur distinct qui ressemble à l'environnement de production, mais sert à tester le projet avant de le publier. Il inclut la dernière version du code, des données de test et permet aux utilisateurs d’évaluer le projet avant de le publier. Aucun développement ne devrait se produire ici.
Bien qu'aucun développement ne devrait avoir lieu ici, il n'est pas rare de disposer de divers outils de débogage afin de générer des messages de journal ou de vérifier ce qui entre et qui sort de la base de données tout en travaillant sur le site..
Étant donné que les développeurs engagent souvent un ensemble de modifications dans le référentiel, elles doivent être testées. C'est ici qu'intervient l'environnement de transfert. De manière générale, l’environnement de transfert s’applique souvent aux dernières modifications apportées au référentiel..
Mais cela soulève deux questions:
Tout d’abord, c’est une bonne chose: cela signifie que l’environnement de rassemblement a bien rempli sa fonction! De plus, cela nous donne l'occasion d'examiner notre code source afin de déterminer si un bogue doit être résolu ou si une nouvelle fonctionnalité doit être introduite..
Et c’est là que le contrôle de source est utile.
Si un bogue s'est produit, vous pouvez vous pencher dans le sens de l'annulation du changement, mais cela n'est pas nécessaire dans l'environnement de stockage intermédiaire. Au lieu de cela, il vous suffit de localiser le bogue, de le résoudre, de valider le code, puis de le redéployer dans l'environnement de stockage intermédiaire pour le tester..
Vous répétez ce processus jusqu'à ce qu'aucun bogue n'existe ou, plus précisément, vous ne puissiez localiser aucun bogue..
Si vous ne parvenez pas à localiser les bogues, vous avez essentiellement ce que l'on appelle une version stable. À ce stade, vous pouvez étiqueter - ou apposer un tampon, une étiquette ou toute autre convention proposée par votre système de contrôle de code source - une version de votre code et la déployer dans l'environnement de production..
Bien sûr, il est possible qu'un bogue soit découvert après son déploiement dans l'environnement de production. Dans ce cas, des mesures spéciales doivent être prises.
L'environnement de production est synonyme du site en direct. C'est ici que les utilisateurs réels créent, gèrent et interagissent avec les données réelles. Aucun développement ne devrait se produire ici.
Il y a très peu de choses à dire sur l'environnement de production en ce qui concerne le développement. Après tout, cela ne devrait être rien de plus que lorsque le code source est déployé pour que les autres puissent l’utiliser..
Mais il y a une chance qu'un bogue soit publié ici. Quand cela arrive, ce est quand une restauration devrait se produire. En termes simples, une restauration survient lorsque vous prenez le dernier jeu de modifications et annulez littéralement le déploiement en restaurant le projet dans son état précédent..
Avant d'effectuer une restauration, notez toutes les étapes de recréation afin de pouvoir les reproduire à la fois dans l'environnement de transfert et dans l'environnement de développement afin de résoudre correctement le problème..
À partir de là, effectuez le développement nécessaire à la résolution du problème, validez une autre modification, déployez-la dans l'environnement de stockage intermédiaire et déployez-la dans l'environnement de production, en supposant qu'elle passe les tests..
Évidemment, cet article en particulier couvre les concepts de haut niveau: nous n'explorons ni les systèmes de contrôle de version les plus adaptés ni les outils les plus adaptés à votre système d'exploitation. Ces sujets sortent du cadre de cet article et méritent chacun leur propre série..
Cependant, dans le concept de développement professionnel WordPress, ces pratiques peuvent évidemment s'avérer utiles pour le développement, les tests et le déploiement (et la restauration) des versions de votre projet..
Dans le dernier article, nous examinerons divers outils disponibles qui nous permettront de diagnostiquer de nombreuses erreurs dans notre environnement de développement local dans le but d’empêcher nombre d’entre elles d’atteindre même l’environnement intermédiaire..
Accentsconagua