Déploiement Dev, Stage et Production pour les sites WordPress?


41

Donc, je dois pouvoir 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 principale. configuration de ... enfin presque tout.

Alors 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.?


pantheon.io a dev, tester et vivre pour un seul domaine. Ils utilisent git pour les fichiers et transfèrent la base de données entre eux en un seul clic. C'est gratuit d'essayer et vous ne payez que lorsque vous êtes en direct - youtube.com/watch?v=KpGTDeqwgX4
jgraup

Réponses:


27

Je suis assez fier de ma configuration et cela 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 / la mise à jour d'un plugin, de l'ajout / de la 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 tout aussi facilement utiliser github ou gitolite . En git, j'ai deux branches "spéciales", masteret 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 des unités thématiques . 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. Lorsque j'ai initialement configuré cette structure, j'ai pensé que cela serait crucial et j'ai donc commencé à écrire un ensemble d'outils pour le faire, mais à ma grande surprise, ils n'étaient vraiment pas nécessaires. (note: comme ils n'étaient pas nécessaires, je ne les ai jamais finis, donc il y a des bugs, par exemple, cela remplacera le domaine dans les données sérialisées).

Environnement de rassemblement

Lorsque les commits sont poussés de la developbranche 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 masterbranche, ils sont automatiquement déployés sur le serveur de production.

Le problème wp-config.php

Vous voulez wp-config.phpêtre unique d'un serveur à l'autre, mais vous souhaitez également le conserver sous contrôle de version. Ma solution consistait à utiliser .gitignorepour ignorer wp-config.phpet stocker les versions intermédiaire et de production en tant que fichiers portant un nom différent. Puis sur chaque serveur, je symlink par exemple wp-config.php -> wp-config-production.php. Chaque utilisateur conserve ensuite sa propre base de données avec ses propres informations d'identification, avec ses propres paramètres wp-config.php (non suivis).

Autres notes

J'utilise Rackspace Cloud , ce qui est phénoménal et peu coûteux. 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 paru nécessaire.

La structure maître / développement imite partiellement le modèle de ramification de Vincent Driessen . J'utilise aussi son extension git git-flow et je le suggère aussi fortement.

Une dizaine de développeurs travaillent hors de cette structure depuis plus d’un an et c’est un rêve de travailler avec. Fiable, sécurisé, rapide, fonctionnel et agile, rien de plus!


Je suis sur le point de configurer une installation de wp de la même manière (mais nous utilisons svn) et je voulais confirmer votre processus de mise à jour des plugins et de wp: terminer la mise à jour et vérifier dev, valider les modifications, les déployer dans la mise en scène, vérifier, couler en direct. En résumé, vous ne faites jamais réellement une mise à jour d'installation wp sur le serveur actif, vous apportez les modifications via des mises à jour dans le référentiel?
Paullb

1
Qu'en est-il des modifications apportées à la base de données par la routine de mise à jour. Comment sont-ils affectés à la base de données de production?
Paullb

Ce flux de travail est correct @paullb et vous n'avez pas à vous soucier des mises à jour de la base de données. De la manière dont WordPress fonctionne, les mises à jour sont déclenchées après la détection de la modification. Cela fonctionne donc exactement de la même manière qu'une mise à jour manuelle (vers le noyau ou un plugin) fonctionne!
Matthew Boynes

@ MatthewBoynes, bonjour. utilisez-vous toujours ce worklow pour votre développement? Si tel est le cas, je vais appliquer ce flux de travail à mon projet. merci :)
Khakiout

Je ne le fais pas, mais uniquement parce que cela ne s'applique pas aux projets sur lesquels je travaille actuellement, qui sont principalement hébergés sur WordPress.com VIP. Si cela était applicable, je l'utiliserais quand même (et en fait, l'entreprise pour laquelle j'ai travaillé auparavant continue de l'utiliser).
Matthew Boynes

4

Tout d'abord, je pense qu'il est important de considérer ce que vous allez dans Version Control. Je recommande contre mettre tout le 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.

Etant donné ça, 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: Extraire 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: extraire une étiquette 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.


Un environnement de développement est très bien adapté aux tests nocturnes, et git wordpress est mis à jour automatiquement toutes les 30 minutes. En plus d’être décentralisé et de mieux fonctionner pour les équipes, je ne connais personne qui soit passé à git / hg retourné. à utiliser svn.
Wyck

1
Juste curieux de savoir pourquoi vous ne placez pas tout le répertoire WP sous contrôle de version. Cela semble être un goulot d'étranglement dans le flux de travail. Mettre WP dans le référentiel donne à tous les développeurs le même codebase et la même version de WP. Cela permet également la cohérence entre les environnements. Voir le lien de Wyck (sur sa réponse) aux fichiers conditionnels de wp-config.
Brian Fegter

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.


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 .gitignoreou git update-index --assume-unchanged config.php(lisez un peu la commande assumée-non modifié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 suit: "si url du serveur = dev, utilisez les informations d’authentification A, sinon utilisez les informations d’authentification B", etc.

Mark explique cela mieux, http://markjaquith.wordpress.com/2011/06/24/wordpress-local-dev-tips/

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 http://www.youtube.com/watch?v=8ZEiFi4thDI )

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.