Déploiement des développeurs, des étapes et de la production pour les sites WordPress?

41

Il faut donc que je puisse avoir des itérations dev / stage / production (sur des serveurs séparés) pour un site Web WordPress. J'utilise généralement git, mais cela ne fonctionnera évidemment pas avec les sites WordPress en raison de la dépendance à la base de données pour la configuration principale de ... eh bien, presque tout.

Donc ma question est: comment faites-vous les gars? J'avais un rapide Google et vu qu'il y avait quelques plugins, est-ce le seul moyen? Lesquels font le meilleur travail en termes de facilité d'utilisation, de rapidité, de fiabilité, d'interface utilisateur, etc.?

    
posée Rob Vermeer 18.01.2012 - 18:22

4 réponses

27

J'ai une configuration dont je suis assez fier et qui fonctionne extrêmement bien pour mon équipe.

Structure générale

Je garde toute l’installation sous git. Toutes les modifications, qu’il s’agisse d’une mise à jour du système, de l’ajout / mise à jour d’un plugin, de l’ajout / mise à jour d’un thème, passent par le même flux de travail. Les modifications peuvent être annulées à tout moment. J'ai un serveur de déploiement (un ancien poste de travail P4) exécutant gitosis , mais vous pouvez également utiliser github ou gitolite . En git, j'ai deux branches "spéciales", master et develop (expliqué plus en détail ci-dessous). Mes serveurs de production et de stockage intermédiaire sont basés sur le cloud.

Environnements de développement

Chaque développeur exécute son propre serveur de développement sur sa propre machine. En termes de bases de données, le besoin de données en temps réel n’a pratiquement jamais été un problème. Nous utilisons principalement les données de test d'unité de thème . Sinon, l'exportation et l'importation couvrent la plupart des choses. Si la pièce de base de données était cruciale, vous pouvez configurer la réplication ou quelque chose pour la synchronisation à la demande. Lors de la configuration initiale de cette structure, j’ai pensé que cela serait crucial et j’ai donc commencé à écrire un ensemble d’outils pour faites cela, mais à ma grande surprise, ils n'étaient vraiment pas nécessaires. (Remarque: comme ils n'étaient pas nécessaires, je ne les ai jamais finis. Il y a donc des bogues, par exemple, ils remplaceront le domaine dans les données sérialisées).

Environnement intermédiaire

Lorsque les commits sont transférés de la branche develop vers gitosis, ils sont automatiquement déployés sur notre serveur de transfert. La base de données de transfert est un esclave de la base de données de production.

Environnement de production

Lorsque les commits sont envoyés à gitosis sur la branche master , ils sont automatiquement déployés sur le serveur de production.

Le problème wp-config.php

Vous souhaitez que wp-config.php soit unique d'un serveur à l'autre, mais vous souhaitez également le conserver sous contrôle de version. Ma solution consistait à utiliser .gitignore pour ignorer wp-config.php et à stocker les versions intermédiaire et de production dans des fichiers portant un nom différent. Ensuite, sur chaque serveur, je lie par exemple un lien symbolique. wp-config.php -> wp-config-production.php . Chaque utilisateur conserve ensuite sa propre base de données avec ses propres informations d'identification, ainsi que ses propres paramètres wp-config.php (non suivis).

Autres notes

J'utilise Rackspace Cloud , une solution phénoménale et peu coûteuse. Je peux ainsi garder mes serveurs de transfert et de production identiques. J'écris aussi actuellement des plugins qui utilisent leur API pour me permettre de contrôler mes services directement à partir de WordPress, c'est merveilleux.

Les répertoires de cache, les répertoires de téléchargement de fichiers, etc., sont tous ajoutés à .gitignore. Si vous le souhaitez, vous pouvez configurer une tâche cron pour vérifier régulièrement les téléchargements et les pousser à la gitose, mais cela ne m’a jamais semblé nécessaire.

La structure maître / développement est définie pour imiter partiellement le modèle de création de succursales de Vincent Driessen . J'utilise également son extension git git-flow et je le suggère aussi strongment.

Depuis environ un an, une dizaine de développeurs travaillent hors de cette structure et c'est un rêve de travailler avec. Fiable, sécurisé, rapide, fonctionnel et agile, vous ne pouvez rien demander de plus!

    
réponse donnée Matthew Boynes 13.02.2012 - 05:38
4

Tout d'abord, je pense qu'il est important de considérer ce que vous allez utiliser dans Contrôle de version. Je recommanderais contre de placer l'intégralité du répertoire WP sous VC. Je pense qu'il est plus logique de placer wp-content / themes / YourThemeName sous VC. Pour un site de grande taille avec un grand nombre de plugins complexes, je pouvais également inclure wp-content / plugins. Si vous deviez absolument le faire, vous pouvez inclure wp-content / uploads. Les réponses ci-dessous vont changer un peu, en fonction de votre contrôle de version.

Cela étant dit, voici ce que j'utilise:

Local: Configurez une pile LAMP sur votre machine. Utilisez la même URL que votre site de développement. Utilisez les entrées de fichier VirtualHosts et .host pour simuler l'environnement de développement d'un point de vue URL. Si vous ne faites que filmer votre thème, envisagez d'utiliser SSHFS pour créer un lien vers wp-content / plugins, wp-content / uploads. Pensez à utiliser la base de données sur votre installation de développement du projet, à moins que vous ne fassiez vraiment de gros travaux.

Développement: extrayez une copie de travail de votre pension dans votre environnement WP. Configurez un crochet POST-COMMIT dans SVN pour mettre à jour ce référentiel à chaque validation. Cela le gardera synchronisé. (Considérez cela comme une intégration continue du pauvre.)

Production: extrayez une balise de version nommée représentant un candidat final. Lorsque vous devez utiliser une nouvelle version, changez l’étiquette et mettez à jour le référentiel.

    
réponse donnée Ethan Seifert 19.01.2012 - 01:48
2

Nous avons récemment découvert RAMP . Remarque: il ne s'agit que d'une partie du processus mais la synchronisation des bases de données de contenu entre serveurs est probablement la partie la plus difficile.

    
réponse donnée lkraav 04.02.2012 - 17:56
2

Je le fais avec git et mercurial, assurez-vous simplement que vous utilisez un dépôt privé.

Option 1.

Le seul problème est le fichier config.php, que vous pouvez dire à git d'ignorer lors du push ou avant init.

Utilisez .gitignore ou git update-index --assume-unchanged config.php (lisez un peu la commande supposée inchangée avant de l'utiliser)

Options 2.

Utilisez une condition dans le fichier config.php qui vérifie l’URL et applique les informations d’identification correctes, comme indiqué ci-dessous: "si url du serveur = dev, utilisez les informations d’authentification A, sinon utilisez les informations d’authentification B", etc.

.

Mark explique mieux cela, enlace

ps. Vous pouvez également serveur les fichiers directement à partir d'un dépôt distant au lieu d'avoir un "serveur de fichiers" traditionnel. (Vidéo vraiment ennuyeuse que j'ai faite à propos de cette enlace .

    
réponse donnée Wyck 04.02.2012 - 20:22

Lire d'autres questions sur les étiquettes