Comment gérez-vous votre build [en utilisant Phing] processus?

Question

Je suis en train d'utiliser Phing pour automatiser:

• tests de fonctionnement
• en cours d'exécution migrations de DB sur chaque machine Developer [en utilisant dbdeply]
• Déploiement à la production en cas de besoin

Je pense qu'il est logique d'ajouter un dossier de construction dans mon projet et de mettre tous mes fichiers de configuration de build et deltas db dans ce dossier. et engager tout cela dans le dépôt SVN. de sorte que chaque développeur obtenir les fichiers de construction mis à jour quand il check-out de svn. et être en mesure d'exécuter la construction de mettre à jour sa base de données avec les nouveaux changements.

sur le serveur de production: Je comptais ajouter un autre fichier de construction là pour obtenir la dernière version tagué svn et effectuer la compression CSS et JS.

---

Je comptais mettre en œuvre continue l'intégration à l'aide phpUnderControl aussi, donc je peux garder une trace du résultat de chaque construction et être averti chaque fois que la construction échoue.

, pensez-vous que tout cela est logique, ou vous avez d'autres meilleures suggestions?

Answer 1

Ce que vous dites est logique. Il est assez proche de ce que j'utilise souvent (parfois avec des fourmis, parfois avec phing, et parfois avec quelques scripts shell)

Dans le répertoire build, j'aurais quelque chose comme ceci:

build/
    testing/
    development/
    staging/
    production/
    common/

Avec un fichier build.xml dans chaque sous-répertoire - tous, y compris un autre fichier build.xml, situé dans le répertoire common, l'idée étant de mettre autant de code « commun » que possible dans le fichier build.xml « commun », et d'avoir par environnement fichiers spécifiques, qui contiennent seulement le code xml possible.

Cela peut être fait avec le import tâche qui existe dans la dernière version de phing (pas sûr qu'il est dans la version stable - J'utilise une caisse SVN de phing, d'avoir celui-ci, pour le projet, je travaille actuellement sur) .

Une chose, cependant: vous dites que vous voulez déployer à la production à partir du serveur de production; Je préfère, à la place:

• sur un serveur « développement »:
  • export de SVN
  • compresser JS / CSS et tout ce que
  • créer une archive tar.gz
• télécharger cette archive sur le serveur de production
• sur le serveur "de production":
  • un-compress que téléchargé l'archive
  • changer quelques symlink pour utiliser la nouvelle version des sources (voir la réponse que j'ai donné ici , pour plus d'informations)
  • mettre à jour ce qui doit être fait dans le DB

L'idée étant à:

• faire aussi peu de choses que possible sur le serveur de production
  • juste au cas où quelque chose va mal
  • et dans le cas, un jour, votre serveur de production n'a pas accès au serveur SVN
• d'avoir une archive physique qui peut être déployé sur plusieurs serveurs de production

Oh, et, comme sidenote: vous devez écrire une sorte de documentation de « comment déployer à la production », étape par étape

Ce sera vraiment utile le jour où vous êtes en vacances et que quelqu'un d'autre à déployer à la production en raison d'un bug-fix d'urgence; -)