Automatisation du développement et de la mise en œuvre de Wordpress

Question

Est-ce que quelqu'un a déjà travaillé sur un projet WordPress avec plusieurs développeurs dans différents endroits? Existe-t-il des bonnes pratiques concernant les équipes de développement distribuées et les déploiements automatisés? J'ai une équipe de différents degrés de développeurs, y compris des développeurs de plugins, des développeurs de thèmes, et de simples tweakers de style CSS, dans quelques endroits différents, et je voudrais mettre en place un bon système pour que tout le monde puisse travailler leurs pièces séparées et déploient en permanence des changements sans perturber le code de quelqu'un d'autre.

Le système exécute une installation de WordPress-MU pour le moment, et il sera éventuellement mis à jour vers la version 3.0. Idéalement, nous devrions stocker les thèmes et les plugins dans le contrôle de source, et puisque quelques modifications ont été apportées au code de base de WordPress, il doit aussi aller dans le dépôt. Je n'arrive pas à trouver la meilleure façon de structurer le référentiel et de faire des déploiements contrôlés mais quelque peu automatisés. Comment gérez-vous le travail et le déploiement dans les environnements de développement, de test, de stockage intermédiaire et de production, lorsque différents types de plugins et de thèmes peuvent stocker des configurations sur le système de fichiers ou dans la base de données? Je me rends compte que la réponse peut être « Ne pas utiliser WordPress, » mais en supposant que je dois, laissez-moi savoir ce que vous pensez,

Merci pour votre aide,

Dave

Answer 1

Voici comment j'ai fini par résoudre ce problème jusqu'à présent:

répertoires de code source:

build/ - build files for phing and environment-specific properties files 
    build.xml 
    src_qa.properties - properties to use the qa server as the source for a deployment 
    dst_qa.properties - properties to use the qa server as the destination for a deployment 
    etc... for other environments 
conf/ - contains environment specific configuration files, each in a subfolder named after the environment 
    dev/ 
     db-config.php - config file for HyperDB - http://codex.wordpress.org/HyperDB 
     default - Apache conf that holds ServerAlias configs for multi-site WordPress 
     hosts - useful for developers to redirect their browser to various domains in different environments 
     htaccess.dist - for WPMU 
     httpd.conf - main Apache config file, specific to each environment 
     my.cnf - mysql config file 
     wp-config.php - main wordpress config file 
    qa 
     (same as dev/ but with different values in each file) 
    staging 
     (same as dev/ but with different values in each file) 
    prod 
     (same as dev/ but with different values in each file) 
src/ - wordpress source code 
    wp-admin/ 
    wp-content/ 
     mu-plugins/ 
     plugins/ 
     themes/ 
    wp-includes/ 
test/ - holds WP test suite and custom tests for plugins, themes, etc... 

J'utilise Hudson CI Server (http://hudson-ci.org/) à la automatisé et construit manuellement à l'aide des tâches de caisse de subversion , phing, et phpunit, etc ... Fondamentalement, le serveur Hudson tire le code de subversion en fonction de ce que vous voulez déployer, et il rsync les fichiers à déployer du serveur CI sur le serveur de destination. Ou, dans le cas d'un déploiement de la mise en scène directement en production, Hudson rsync les fichiers de la mise en scène, jusqu'au serveur CI, puis la sauvegarde en production.

J'ai construire la configuration des emplois dans hudson pour les pièces de fonctionnalités suivantes:

core WP code - deploys core WP files and mu-plugins from src to dst 
    svn to qa 
    svn to staging 
    staging to prod 
WP plugins/ folder - deploys only the plugins folder 
    svn to qa 
    svn to staging 
    staging to prod 
WP themes/ folder - deploys the entire themes folder 
    svn to qa 
    svn to staging 
    svn to prod 
Specific themes - deploys a specific theme (chosen through a drop down during the build process using Hudson's parameterized build feature - http://wiki.hudson-ci.org/display/HUDSON/Parameterized+Build) 
    svn to qa 
    svn to staging 
    svn to prod 

Les emplois hudson ont également la possibilité de déployer l'environnement des fichiers PHP spécifiques (par exemple wp-config.php, db-config. php), ainsi que les fichiers de configuration Apache et MySQL aux emplacements appropriés sur chaque serveur. Dans certains cas, nous déployons sur plusieurs serveurs Web et plusieurs serveurs de base de données, et la plus grande partie de la configuration de construction est prise en charge par le fichier de construction phing et les fichiers .properties mentionnés ci-dessus. À l'avenir, lorsque nous aurons un environnement d'intégration de développement, nous effectuerons probablement des déploiements automatisés lors de la vérification svn de n'importe quel code.Cette configuration permet à différents développeurs de l'organisation ayant des compétences différentes (CSS/HTML ou PHP principalement) de travailler séparément et de faire évoluer rapidement leur code vers les environnements appropriés sans impliquer un tas de personnes inutiles. Hudson me permet de verrouiller différentes tâches de déploiement afin que seules les bonnes personnes aient accès à leur configuration et à leur coup d'envoi.

C'est un peu un aperçu de haut niveau de ce que j'ai configuré, laissez-moi savoir ce que vous pensez. Les plus gros ennuis avec cette configuration étaient des paires de clés, des comptes d'utilisateurs et des permissions de fichiers avec rsync sur tous les différents serveurs.

Dave

Answer 2

Pour le système de fichiers que nous utilisons GIT et ça marche très bien. Vous pouvez avoir une branche pour chaque membre de l'équipe, puis la fusionner dans la branche de production. Nous pouvons garder notre code intégré sans aucun problème.

Pour la base de données, je continue de jeter la base de données prod et de la partager avec tout le monde (vous pouvez même l'envoyer au dépôt GIT et tout le monde aura le dernier vidage).