Aide de Wordpress Git Workflow

Question

Je recherche une idée de flux de travail rationalisé pour travailler avec Wordpress.

Voudrais avoir mon environnement git sur mon propre serveur en interne, sans utiliser Github pour gérer les dépôts.
Création automatique de sous-domaines lors de la création de branches git (development.domain.com, ryan.development.domain.com) - Un hook de script Shell serait probablement idéal pour cela.
Phing PHP/script Shell Gestion de la migration de la base de données (quelque chose comme ceci http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ) pour gérer le remplacement de la base de données sérialisée lors du transfert

Opération serait probablement aller quelque chose comme ça:

obtenir la dernière version de wordpress et la brancher, le nom de la branche reçoit une entrée de sous-domaine (branchdevelopment.domain.com)
sous-modulez le thème que vous désirez s'il est disponible (j'aimerais créer mon propre dépôt git pour cela, car j'utilise une thèse, j'aimerais disposer d'une configuration de rapport vierge git pour thèse à récupérer en interne sur le serveur déjà créé)
passer la commande et apporter des modifications, les avis clients, une fois activé, le script de base de données modifie automatiquement les valeurs de l'URL sérialisée de localhost (ou sous-domaine) à l'URL dynamique.

Est-ce possible? J'ai entendu dire que Capistrano était également bon à utiliser avec cela, mais je ne savais pas comment Capistrano fonctionnait entièrement.

Je gère environ 200 sites sur mon propre serveur et j'aimerais commencer à implémenter ces sites dans un environnement de flux de travail git puissant afin que je puisse rationaliser mon travail beaucoup mieux. À partir de maintenant, je télécharge une image du site et le travaille localement, puis je télécharge les modifications sur le serveur. C'est très fastidieux de nos jours.

Est-ce que quelqu'un a des solutions concernant ce type de flux de travail/a déjà travaillé avec cela dans le passé? Si oui, des ressources/réponses seraient grandement appréciées.

kaiser · Accepted Answer

Questions générales répondues

Nr.1. Je voudrais avoir mon environnement git sur mon propre serveur en interne, sans utiliser Github pour gérer les dépôts.

La première chose que je ferais est de vérifier composer et son fonctionnement avec WordPress , qui est un projet de Andrey "@Rarst" Savchenko .

Nr.2. Création automatique de sous-domaines lors de la création d'une branche git (development.example.com, ryan.development.example.com) - Un hook de script Shell serait probablement idéal pour cela.

C'est quelque chose hors de portée pour ce site. Demandez de l'aide sur StackOverflow ou demandez à votre hébergeur. Certains hébergeurs n'autorisent pas la modification de ces entrées vous-même.

Nr.3. Phing Script PHP/Shell Gestion de la migration de la base de données (comme ceci http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ) pour gérer le remplacement de la base de données sérialisée poussant

Je mettrais en place une installation multisite/réseau. Cela permet de gérer facilement toutes les tables, de garder les utilisateurs dans un endroit central, etc.

WP Gear - un projet de Robert "@Wyck" Ellison - a une liste de scripts de construction alternatifs. Incluant WordPhing écrit par lui-même. @TomJNowells /Interconnect.it script n'est pour l'instant pas dans cette liste).

Opération Questions répondues

Nr. 1. obtenir la dernière version de wordpress actuelle et la brancher, le nom de la branche obtient une entrée de sous-domaine (branchdevelopment.domain.com)

Vous ne savez pas pourquoi on veut faire cela: un sous-domaine pour chaque branche. Lorsque vous regardez le répertoire synchronisé référentiel WordPress GitHub et le répertoire liste des branches , vous constaterez que chaque branche s'appelle X.Y-branch. Ainsi, vos sous-domaines sont nommés, par exemple, 3.6-branch. Je ne suis pas sûr si un sous-domaine est autorisé à commencer par un chiffre (il devrait l'être, mais renseignez-vous auprès de votre hébergeur), puis vous rencontrerez le problème suivant: vous obtenez un sous-sous-domaine nommé 6-branch, qui comporte un sous-sous-sous-domaine nommé 3 et un autre. named 2. Et devinez association _ Les branches à 2 et 3 versions dans un sous-domaine ne sont pas ce que vous voulez atteindre.

En bref: Juste checkout 3.6-branch si vous devez changer de branche.

Nr.2. submodule le thème que vous désirez s'il est disponible (j'aimerais créer mon propre dépôt git pour cela, car j'utilise une thèse, j'aimerais disposer d'une configuration de git de mémoire vierge à récupérer en interne sur le serveur déjà existant. été créé)

Thomas "@toscho" Scholz a écrit un plugin Nice qui permet d'utiliser un sous-domaine pour gérer des thèmes en dehors du répertoire WordPress. Vous le trouverez dans this answer ainsi que dans celui-ci . Même les mises à jour automatiques fonctionneront pour les thèmes puisque WP 3.6.

Vous pouvez faire la même chose pour MU-Plugins and Plugins en définissant simplement les constantes suivantes dans votre fichier wp-config.php:

define( 'WP_PLUGIN_DIR', 'path/to/your/plugins.dev/folder/plugins' ); define( 'WP_PLUGIN_URL', 'https://plugins.dev/plugins' ); define( 'WPMU_PLUGIN_DIR', 'path/to/your/plugins.dev/folder/mu-plugins' ); define( 'WPMU_PLUGIN_URL', 'https://plugins.dev/mu-plugins' );

Maintenant, placez simplement tous vos plugins et thèmes sous contrôle de version et envoyez-les sur votre serveur. Vous pouvez facilement les rendre tous disponibles en utilisant soit mu-plugins, soit des plugins par défaut activant le réseau.

Nr.3 checkout et apportez des modifications, commentaires de clients, une fois mis en production, le script de base de données démarrera automatiquement en modifiant automatiquement les valeurs de l'URL sérialisée de localhost (ou sous-domaine).

Si le script/plugin de Toms ne vous aide pas jusqu'à présent, alors soyez averti que qu'il accepte la demande de retrait sur GitHub .

hakre · Answer

Pas le temps d'écrire une réponse complète (je sais un peu nul), mais ça vaut probablement la peine de partager quand même (je pourrais l'éditer parce que je planifie un post sur ce blog également):

Je clone Wordpress à partir de Github (vous pouvez même le faire pour l'arbre source à partir d'ici: tierra/wordpress )
Je l'utilise ensuite comme via un sous-arbre de fusion dans le dépôt de mon propre site (j'ai même rencontré un bogue dans git mais la solution est ici: -X sous-arbre = ... ).

Cela signifie que vous pouvez avoir une configuration WP basée sur le tronc ou la branche de version que vous pouvez complètement pirater. thèmes et plugins.

S'agissant d'un référentiel indépendant (local), vous pouvez le transmettre via ssh à d'autres référentiels, par exemple:

Cela repose sur l'hôte distant sur lequel le site doit être déployé (dépôt nu).
Des crochets permettent de faire fusionner un autre référentiel sur cet hôte dans les modifications que vous venez de mettre en place.

Ceci est décrit dans Un flux de travail Git centré sur le Web (nov. 2008; par Joe Maller) .

Si vous disposez ensuite d'un commutateur de configuration qui choisit le wp-config.php concret en fonction du système sur lequel il s'exécute, vous pouvez même configurer de manière centralisée tous les hôtes (développement, live, transfert, amis, ...) à l'intérieur du référentiel.

Les modifications en amont dans WP ne sont que l'extraction et la fusion dans la sous-arborescence.

Les plugins que vous venez de mettre à jour et de valider.

Le déploiement est un simple $ git Push remote.

Exécutez des sauvegardes quotidiennes sur l'hôte distant pour les dépôts git, la base de données et les fichiers téléchargés, ce qui est économique, convivial et flexible pour les développeurs. Cela fonctionne bien pour les configurations à développeur unique ainsi que pour les petites équipes car tout le monde peut passer à la caisse depuis la reproduction nue de la télécommande.

Il y a quelques mises en garde:

Maintenant, avec votre liste de contrôle et la configuration décrite ci-dessus:

1. Voudrais avoir mon environnement git sur mon propre serveur en interne, sans utiliser Github pour gérer les dépôts.

Github ne gère que les dépôts en amont ici (Wordpress), pas le vôtre.

2. Création automatique de sous-domaines lors de la création de branches git (development.domain.com, ryan.development.domain.com) - Un hook de script Shell serait probablement idéal pour cela.

La configuration décrite ci-dessus est une approche modulaire avec une prise en pension par site. Il peut gérer autant d'hôtes de développement que vous le souhaitez. Il pourrait également fonctionner avec une installation multi-site pour gérer plusieurs domaines, mais cela compterait comme une configuration wordpress dans cette approche.

3. Phing PHP/script Shell Manipulation de la migration de la base de données (quelque chose comme ceci http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ) pour gérer le remplacement de la base de données sérialisée lors du transfert

Cela n’est pas nécessaire ici car seul le code est sous contrôle de version, les bases de données sont indépendantes entre le développement (, la mise en scène) et la production, comme il se doit.

Vous êtes peut-être à la recherche d'un script d'installation qui effectue correctement la migration de domaine, mais même avec un meilleur code (disponible) traitant de la recherche et du remplacement de données en série, dans cette configuration, il n'est normalement pas nécessaire, car vous devez simplement appliquer les modifications en direct. , pour les cas de test, vous pouvez rapidement créer le contenu dans la base de données de développement, ce qui est normalement le plus petit problème (d'après mon expérience pratique, le vôtre peut différer, mais je suggérerais également de conserver de tels sujets liés à la propre ici sur le site - mais s'il vous plaît leur demander).

Je gère environ 200 sites sur mon propre serveur et j'aimerais commencer à implémenter ces sites dans un environnement de flux de travail git puissant afin que je puisse rationaliser mon travail beaucoup mieux.

Je ne peux pas imaginer comment ces sites deviendraient sous un environnement de flux de travail string git. Peut-être que les scripts de configuration et les données de configuration que vous gérez ici seront conservés sous contrôle de version git. Cela pourrait avoir un sens. Sinon, vu le nombre impressionnant de sites, je pense que cela n’a aucun sens de garder tous ceux-ci dans un même dépôt. Peut-être même pas l'un d'entre eux, car ce que j'ai décrit ci-dessus concerne les sites que vous développez (y compris le code principal WP -), et pas uniquement les tâches d'installation. Il est donc probablement nécessaire de commencer par créer vous-même une petite carte de ces 200 sites et de la manière dont ils interagissent les uns avec les autres, ainsi que des packages (noyau WP, plugins, thèmes) composant ces sites. La première chose à faire pourrait être de créer un tableur/matrice et de mettre tous les sites en po.

Vous pouvez ensuite l'enregistrer en tant que CSV, le placer sous contrôle de version et faire en sorte que les scripts de déploiement fonctionnent à partir de ce fichier.

Et si j’ai appris quelque chose avec les tâches automatisées: suivez la philosophie Unix, utilisez les outils existants et performants (il est préférable de passer une demi-journée à lire certaines commandes plutôt que de chercher des alternatives, car pour la plupart des tâches, déjà résolu) et se concentrer sur les outils en ligne de commande. Ils sont les plus puissants.