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!