Aide de Wordpress Git Workflow

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

1. J'aimerais avoir mon environnement git sur mon propre serveur en interne, sans utiliser Github pour gérer les repos.
2. Création automatique de sous-domaines lors de la création de la branche git (development.domain.com, ryan.development.domain.com) - Probablement un hook de script shell serait idéal pour cela.
3. Phing PHP / Shell script 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 de la poussée

Le fonctionnement aurait probablement quelque chose comme ceci:

1. obtenir la dernière version wordpress actuelle et la dériver, le nom de la branche obtient une entrée de sous-domaine (branchdevelopment.domain.com)
2. sous-module le thème que vous désirez s'il est disponible (je voudrais faire mon propre git repo pour cela, car j'utilise une thèse, je voudrais avoir une configuration de git repo vide pour récupérer en interne sur le serveur qui a déjà été créé)
3. vérifier et apporter des modifications, les avis des clients, une fois qu'il est poussé à vivre, le script de base de données va alors automatiquement changer les valeurs d'url sérialisées de localhost (ou sous-domaine) à l'url en direct

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

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

Quelqu'un at-il des solutions concernant ce type de flux de travail / a travaillé avec cela dans le passé? Si oui, certaines ressources / réponses seraient grandement appréciées.

Réponses aux questions générales

Nr.1. J'aimerais avoir mon environnement git sur mon propre serveur en interne, sans utiliser Github pour gérer les repos.

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

Nr.2. Création automatique de sous-domaines lors de la création de la branche git ( development.example.com, ryan.development.example.com) - Probablement un hook de script shell serait idéal pour cela.

C'est quelque chose hors de portée pour ce site. Soit demander de l'aide sur StackOverflow ou demander à votre hébergeur. Certains hébergeurs ne permettent pas de modifier ces entrées vous-même.

Nr.3. Phing PHP / Shell script 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 de la poussée

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. Y compris WordPhing écrit par lui-même. Le script @TomJNowells /Interconnect.it jusqu'à présent ne figure pas dans cette liste.

Questions d'opération répondues

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

Je ne sais pas pourquoi on veut faire ça: un sous-domaine pour chaque branche. Lorsque vous regardez le référentiel GitHub WordPress synchronisé et la liste des branches , vous verrez que chaque branche est nommée X.Y-branch. Ainsi, vos sous-domaines seraient nommés par exemple 3.6-branch. Je ne sais pas si un sous-domaine est autorisé à commencer par un chiffre (il devrait l'être, mais demandez à votre hébergeur) et puis il y a le problème que vous obtiendrez un sous-sous-domaine nommé 6-branch, qui a un sous-sous-sous-domaine nommé 3et un autre nommé 2. Et devinez que l' association de branches à 2 et 3 versions dans un sous-domaine n'est pas ce que vous voulez atteindre.

En bref: juste checkout 3.6-branchsi vous avez besoin de changer de branche.

Nr.2. sous-module le thème que vous désirez s'il est disponible (je voudrais faire mon propre dépôt git pour cela, car j'utilise la thèse, je voudrais avoir une configuration de dépôt git de thèse vierge à récupérer en interne sur le serveur qui a déjà été créé)

Thomas "@toscho" Scholz a écrit un joli plugin qui nous permet d'utiliser un sous-domaine pour gérer des thèmes en dehors du répertoire WordPress. Vous pouvez le trouver dans cette réponse ainsi que dans celle-ci . Même les mises à jour automatiques fonctionneront pour les thèmes depuis WP 3.6.

Vous pouvez faire de même pour les plugins MU et les plugins en définissant simplement les constantes suivantes dans votre wp-config.phpfichier:

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, mettez simplement tous vos plugins et thèmes sous contrôle de version et poussez-les sur votre serveur. Vous pouvez facilement les rendre tous disponibles en utilisant soit des plugins mu, soit des plugins par défaut qui activent le réseau.

N ° 3 check-out et apporter des modifications, les avis des clients, une fois qu'il est poussé à vivre, le script de base de données va alors automatiquement changer les valeurs d'url sérialisées de localhost (ou sous-domaine) à l'url en direct

Si le script / plugin Toms ne vous aide pas jusqu'à présent, alors dites - lui qu'il accepte la demande de pull sur GitHub .

Pas le temps d'écrire une réponse complète (je sais une sorte de boiteux) mais ça vaut probablement la peine de partager de toute façon (je pourrais éditer cela parce que je prévois également un blog sur ce sujet):

• Je clone Wordpress depuis Github (vous pouvez même le faire pour l'arborescence source d'ici: tierra / wordpress )

• Je l'utilise ensuite comme via une fusion de sous - arborescence dans mon propre dépôt de sites (j'ai même écrasé un bogue dans git mais sa solution est ici: -X sous-arborescence = ... ).

Cela signifie que vous pouvez avoir une configuration WP basée sur un tronc / branche de version que vous pouvez entièrement pirater. thèmes et plugins.

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

• Cela se trouve sur l'hôte distant sur lequel le site doit être déployé (repo nu).
• Cela a des crochets pour faire fusionner un autre référentiel sur cet hôte dans les modifications que vous venez de pousser.

Ceci est décrit dans Un workflow Git axé sur le Web (novembre 2008; par Joe Maller) .

Si vous avez ensuite un sélecteur de configuration qui choisit le béton en wp-config.phpfonction du système sur lequel il fonctionne, vous pouvez même configurer de manière centralisée tous les hôtes (développement, live, staging, amis, ...) à l'intérieur du référentiel.

Les modifications en amont dans WP que vous venez de récupérer et de fusionner dans le sous-arbre.

Plugins que vous venez de mettre à jour et de valider.

Le déploiement est 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 bon marché, convivial pour les développeurs et flexible. Cela fonctionne bien pour les configurations à développeur unique ainsi que pour les petites équipes, car tout le monde peut commander à partir de la simple repro sur la télécommande.

Il y a quelques mises en garde:

• Les alias git git accept-theirset git accept-theirssont utiles en cas de changements de base conflictuels, vous savez clairement lequel vous préférez traiter. Vous le trouvez ici: Outil simple pour 'accepter le leur' ​​ou 'accepter le mien' sur un fichier entier en utilisant git
• Bonjour Dolly. La malédiction d'une génération entière. Vous devez toujours le vérifier.

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

1. J'aimerais avoir mon environnement git sur mon propre serveur en interne, sans utiliser Github pour gérer les repos.

Github gère uniquement 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 la branche git (development.domain.com, ryan.development.domain.com) - Probablement un hook de script shell serait idéal pour cela.

La configuration telle que décrite est une approche modulaire avec un dépôt par site. Il peut gérer autant d'hôtes de développement que vous le souhaitez, il pourrait également bien fonctionner avec une installation multisite pour gérer plusieurs domaines, mais cela compterait comme une configuration wordpress dans cette approche.

3. Script PHP / Shell Phing Gestion de la migration db (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 de la poussée

Ceci 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 (, le staging) et la production comme il se doit.

Vous cherchez peut-être un script d'installation qui effectue la migration de domaine correctement, mais même avec un meilleur code (disponible) traitant de la recherche et du remplacement de données sérialisées, dans cette configuration ici, il n'est normalement pas nécessaire car vous poussez simplement les modifications à vivre , pour les cas de test, vous pouvez créer rapidement le contenu dans la base de données de développement, 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 garder ces sujets liés à la migration de la base de données sur les questions de son ici sur place - mais veuillez les demander).

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

Je ne peux pas imaginer comment ces sites deviendraient sous un environnement de flux de travail avec 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 du sens. Sinon, par la quantité de sites, je pense que cela n'a aucun sens de garder tous ceux-ci dans un seul dépôt git. Peut-être même pas un de ceux-là parce que ce que j'ai décrit ci-dessus concerne les sites que vous développez (y compris le code de base WP), pas seulement les tâches d'installation. Vous devez donc probablement d'abord vous créer une petite carte de ces 200 sites et comment ils interagissent entre eux et à partir de quels packages (noyau WP, plugins, thèmes) ces sites sont constitués. La première chose pourrait être de créer une feuille de calcul / matrice et de mettre tous les sites dedans.

Vous pouvez ensuite l'enregistrer au format CSV, le placer sous contrôle de version et faire en sorte que les scripts de déploiement fassent leur travail en fonction de ce fichier.

Et si j'ai appris quelque chose avec l'automatisation des tâches: suivez la philosophie Unix, utilisez les outils existants et qui fonctionnent bien (il vaut mieux passer une demi-journée à lire sur certaines commandes, puis essayer de rechercher des alternatives car pour la plupart des travaux, les problèmes ont été déjà résolu) et se concentrer sur les outils de ligne de commande. Ils sont les plus puissants.