Est-ce que quelqu'un a un workflow de développement/staging/déploiement avec php/mysql?

Question

Je pense à un bon flux de travail pour le développement web php/mysql.

Quelqu'un a-t-il des conseils?

Answer 1

Voici ce que nous faisons:

1. Tout le monde travaille sur leurs projets dans leur branche (code, les tests, etc.)
2. Quand tout semble bon, il est fusionné dans Trunk
3. phpUnderControl reconstructions du coffre , exécute tous nos phpUnit essais, construit la documentation, mise à jour db, etc
4. Si tout ce qui passe, nous fusionnons Stable
5. Stable entièrement reconstruit comme obtient Trunk
6. Stable est promu manuellement à notre serveur de production

Nous avons quelques scripts personnalisés qui prennent soin de nos mises à jour de base de données et nos efforts en production. Pour notre base de données, nous conservons tous les deltas dans un seul dossier et le script vérifie le niveau de base de données actuel par rapport aux deltas disponibles et, si nécessaire, les applique.

Pour la promotion en production, nous avons un autre script qui extrait toutes les données de production, puis exécute rsync pour accélérer les changements.

Vous ne mentionnez pas le niveau de contrôle que vous avez sur les serveurs, mais le processus global serait le même pour le développement général.

Answer 2

Je pense que tout le monde fait ces choses légèrement différentes, selon l'application exacte. Voici notre configuration:

Avant une sortie:

• Tout le monde s'engage à /trunk.
• Lorsque nous souhaitons lancer une version, nous copions le segment sur /tags/yymmddhhiiss.
• Nous stabilisons l'étiquette.

Une fois qu'il est stabilisé, nous courons le script deploy:

• Sur le serveur de production, la caisse de la nouvelle balise.
• Effectuez une sauvegarde de la base de données.
• Arrêtez les démons et fermez les applications Web.
• Activez le lien symbolique /current pour pointer vers l'étiquette récemment sortie.
• Exécuter des scripts de migration.
• Redémarrez les démons et les applications.

Si nous devons pousser un petit changement rapidement, nous fusionnons à l'étiquette en cours, et nous pouvons ensuite exécuter un processus de correctif beaucoup plus simple au niveau du serveur:

• daemons Stop et fermer la ou les applications Web.
• Exécution svn update
• Redémarrez les démons et les applications.

Notez qu'il existe certains outils qui visent à structurer/automatiser ces processus. Phing est un, et Symfony a son propre batch system, qui était un projet autonome appelé pake. Et comme si cela ne suffisait pas, Zend Framework est sur le point de créer their own variant. C'est vraiment un peu un gâchis, mais Phing est probablement le plus largement utilisé. Vous pouvez également utiliser quelque chose de non spécifique au php, tel que Ant ou Capistrano. Nous utilisons simplement des scripts shell, qui répondent essentiellement au même besoin.

Nous avons également une exécution en continu, qui vérifie à partir du coffre et exécute tous les tests. Actuellement, nous avons juste une collection de base de scripts shell, mais nous envisageons de passer à PhpUnderControl ou xinc.

Les étapes des migrations méritent peut-être une explication. Theese contient des modifications à la base de données, ainsi que d'autres tâches qui doivent être exécutées pour la nouvelle version. Nos migrations sont un peu simples en ce moment; Nous avons simplement un dossier avec un tas de scripts .php et .sql et pendant la migration, ils sont exécutés en séquence. La façon dont nous suivons les changements effectués est de vider le dossier migrations juste après la création d'une nouvelle étiquette. Il serait probablement plus judicieux d'utiliser la base de données pour consigner les modifications qui ont été effectuées. Nous sommes considérés comme adoptant quelque chose comme ruckusing à cette fin.