Quelle est votre stratégie de déploiement php préférée?
Je commence un nouveau projet dans PHP) et j'aimerais connaître l'avis des autres développeurs sur leur stratégie préférée pour le déploiement de PHP. Je J'adore automatiser un peu les choses pour qu'une fois les modifications validées, elles puissent rapidement être migrées vers un serveur de développement ou de production.
J'ai de l'expérience avec les déploiements avec Capistrano avec Ruby), ainsi que des scripts de base pour Shell.
Avant de plonger seul la tête la première, il serait bon d’entendre comment d’autres personnes ont abordé cette question dans leurs projets.
Plus d'informations
Actuellement, les développeurs travaillent sur des installations locales du site et engagent les modifications dans un référentiel Subversion. Les déploiements initiaux sont réalisés en exportant une version étiquetée de svn et en la téléchargeant sur le serveur.
Les modifications supplémentaires sont généralement effectuées au coup par coup en téléchargeant manuellement les fichiers modifiés.
Pour PHP, SVN avec les scripts Phing est le chemin à parcourir. Phing est similaire à ANT mais est écrit en PHP, ce qui facilite beaucoup la tâche des PHP développeurs à modifier pour leurs besoins .
Notre routine de déploiement est la suivante:
- Tout le monde se développe sur le même serveur local au travail, chaque développeur a également une caisse sur sa machine chez lui.
- Les validations déclenchent un hook post-commit qui met à jour un serveur de transfert.
- Les tests sont exécutés sur le serveur de transfert, s’ils réussissent - continuez.
- Le script de compilation Phing est exécuté:
- Désactive le serveur de production, en basculant le domaine sur une page "En construction"
- Exécute la mise à jour SVN à la sortie de la production
- Exécute le script de deltas de schéma
- Effectue des tests
- Si les tests échouent, exécutez le script d'annulation
- Si les tests réussissent, le serveur renvoie à la caisse de production.
Il y a aussi phpUnderControl , qui est un serveur d'intégration continue. Pour être honnête, je n'ai pas trouvé cela très utile pour les projets Web.
Je suis en train de déployer PHP avec Git . Une simple production git Push suffit à mettre à jour mon serveur de production avec la dernière copie de Git. C'est simple et rapide. Parce que Git est assez intelligent pour ne renvoyer que les diffs et non le projet entier. Cela permet également de conserver une copie redondante du référentiel sur le serveur Web en cas de défaillance matérielle de mon côté (bien que j'appuie également sur GitHub pour plus de sécurité). .
Nous utilisons Webistrano , une interface Web pour Capistrano, et nous en sommes très satisfaits.
Webistrano permet des déploiements multi-étapes et multi-environnements à partir de SVN, GIT et autres. Il prend en charge la restauration intégrée, la prise en charge de rôles de serveur distincts tels que Web, db, application, etc., et se déploie en parallèle. Il vous permet de remplacer les paramètres de configuration sur plusieurs niveaux, par exemple, et enregistre les résultats de chaque déploiement, en les envoyant éventuellement par courrier.
Même si Capistrano et Webistrano sont des applications Ruby), la syntaxe du déploiement 'recettes' est assez simple et assez puissante pour être comprise par tout programmeur PHP. À l'origine, Capistrano était construit pour Ruby sur Rails projets, mais accueille facilement PHP projets.
Une fois configuré, il est même assez facile d’être utilisé par des non-programmeurs, tels que les testeurs déployant une version intermédiaire.
Pour fournir le déploiement le plus rapide possible, nous avons installé la méthode fast_remote_cache , qui met à jour un cache svn working-copy sur le serveur distant, puis crée un lien solide avec le résultat.
J'utilise Apache Ant pour déployer sur différentes cibles (dev, QA et live). Ant est conçu pour fonctionner avec le déploiement de Java), mais il fournit une solution de cas général très utile pour le déploiement de fichiers arbitraires.
La syntaxe du fichier build.xml est assez facile à apprendre: vous définissez différentes cibles et leurs dépendances qui s'exécutent lorsque vous appelez le programme ant sur la ligne de commande.
Par exemple, j'ai des cibles pour dev, QA et live, chacune dépend de la cible cvsbuild qui extrait la dernière révision principale de notre serveur CVS, copie les fichiers appropriés dans le répertoire de construction (à l'aide de la balise fileset), puis rsync le répertoire de construction sur le serveur approprié. Il y a quelques bizarreries à apprendre, et la courbe d'apprentissage n'est pas totalement plate, mais je le fais depuis des années sans problème, alors je le recommanderais dans votre cas, mais je suis curieux de savoir quelles autres réponses j'aurais. 'vais voir sur ce fil.
Je fais des choses manuellement en utilisant Git. Un référentiel pour le développement, qui obtient git Push --mirror 'ed sur un repo public, et le serveur live est un troisième repo tiré de cela. Je suppose que cette partie est la même que votre propre configuration.
La grande différence est que j'utilise des branches pour presque tous les changements sur lesquels je travaille (j'en ai environ 5 actuellement), et ont tendance à basculer entre elles. La branche principale n'est pas modifiée directement, à l'exception de la fusion d'autres branches.
J'exécute le serveur en direct directement à partir de la branche principale. Lorsque j'ai terminé avec une autre branche et que je suis prêt à la fusionner, je bascule le serveur sur cette branche pendant un moment. Si ça casse, le remettre au maître prend quelques secondes. Si cela fonctionne, il est fusionné dans master et le code live est mis à jour. Je suppose qu’une analogie avec SVN consisterait à avoir deux copies de travail et à pointer sur la copie active via un lien symbolique.
une alternative aux scripts de déploiement maison consiste à déployer sur une plate-forme en tant que service qui supprime une grande partie de ce travail pour vous. Un PaaS offre généralement son propre outil de déploiement de code, ainsi que son dimensionnement, sa tolérance aux pannes (par exemple, une mise hors service en cas de panne matérielle), et constitue généralement un excellent outil pour la surveillance, la vérification des journaux, etc. bonne configuration connue qui sera mise à jour au fil du temps (un mal de tête de moins pour vous).
Le PaaS que je recommanderais est dotCloud , en plus de PHP ( voir leur PHP quickstart =)) Il peut également déployer MySQL, MongoDB et toute une série de services supplémentaires, ainsi que des avantages tels que le déploiement sans interruption, la restauration instantanée, la prise en charge complète de SSL et de la prise en charge de la Web, etc.
Bien sûr, je suis légèrement biaisé depuis que je travaille là-bas! En plus de dotCloud, Pagodabox et Orchestra (qui font maintenant partie de Engine Yard) sont également intéressants.
J'espère que cela t'aides!
Salomon
Je sais que Phing a été mentionné à quelques reprises maintenant, mais j'ai eu beaucoup de chance avec phpUnderControl . Pour nous nous
- Extraire des copies individuelles de branches sur des machines locales
- Les branches sont testées puis fusionnées dans le coffre
- Les validations vers le tronc sont construites automatiquement par phpUnderControl, exécute des tests et construisent toute la documentation, applique des deltas de base de données.
- Le coffre est soumis à des tests de qualité puis fusionné dans notre branche Stable
- Encore une fois, phpUnderControl construit automatiquement Stable, exécute des tests, génère de la documentation et met à jour une base de données.
- Lorsque nous sommes prêts à passer en production, nous exécutons un script rsync qui sauvegarde la production, met à jour la base de données, puis insère les fichiers. La commande rsync est appelée à la main pour nous assurer que quelqu'un surveille la promotion.
Je suis bien en retard à la fête, mais je pensais partager nos méthodes. Nous utilisons Phing avec Phingistrano , qui fournit une fonctionnalité semblable à Capistrano à Phing via des fichiers de construction prédéfinis. C'est très cool, mais ne fonctionne que si vous utilisez Git pour le moment.
Que vous preniez automatiquement et aveuglément les modifications d'un référentiel vers des serveurs de production semblait dangereux. Que se passe-t-il si votre code engagé contient un bogue de régression, de sorte que votre application de production devient défectueuse?
Mais si vous voulez un système d’intégration continue pour PHP, j’imagine que Phing est le meilleur choix pour PHP. Je ne l’ai pas testé moi-même, cependant, comme je le fais de manière manuelle, par exemple. scp.
Au cours de mon travail, mon équipe et moi-même avons mis au point un substitut orienté Phing pour le déploiement de Capistrano. Nous avons également intégré certains des atouts disponibles dans Phing tels que PHPUnit testing, phpcs et PHPDocumentor. Nous en avons fait un dépôt git pouvant être ajouté à un projet en tant que sous-module dans git et cela fonctionne très bien. Je l'ai attaché à une poignée de projets et il est suffisamment modulaire pour qu'il soit facile de le faire fonctionner avec n'importe quel projet sur n'importe lequel de nos différents environnements (mise en scène, tests, production, etc.).
Avec les scripts de compilation de phing, vous pouvez les exécuter manuellement à partir de la ligne de commande. J'ai également réussi à automatiser les routines de construction/déploiement avec Hudson et maintenant Jenkins ci.
Je ne peux pas poster de liens maintenant car le repo n'est pas encore public, mais on m'a dit que nous allons ouvrir le code source de temps en temps, alors n'hésitez pas à me contacter si vous êtes intéressé ou si vous avez Pour toute question sur l’automatisation de votre déploiement avec phing et git.
Un an de retard mais ... Dans mon cas, le déploiement n'est pas automatique. Je trouve dangereux de déployer du code et d'exécuter des scripts de migration de base de données automatiquement.
Au lieu de cela, les points d'ancrage Subversion sont utilisés pour se déployer uniquement sur le serveur de test/intermédiaire. Le code est déployé en production à la fin d'une itération, après avoir effectué des tests et vérifié que tout fonctionnera correctement. Pour le déploiement proprement dit, j'utilise un fichier Makefile personnalisé qui utilise rsync pour transférer des fichiers. Le Makefile peut également exécuter les scripts de migration sur le serveur distant, suspendre/reprendre les serveurs Web et de base de données.
http://controltier.org/wiki/Main_Page
nous allons l'utiliser pour les déploiements et la maintenance multi-serveurs.
J'ai une copie de travail d'une branche de publication SVN sur le serveur. La mise à jour du site (lorsqu'il n'y a pas de changement de schéma) est aussi simple que d'émettre une commande de mise à jour SVN. Je n'ai même pas besoin de déconnecter le site.
Phing est probablement votre meilleur choix si vous pouvez supporter la douleur des fichiers de configuration XML. Le framework Symfony a son propre portage (pake), qui fonctionne assez bien, mais est assez étroitement couplé au reste de Symfony (bien que vous puissiez probablement les séparer).
Une autre option est d'utiliser Capistrano. Évidemment, il ne s'intègre pas aussi bien avec PHP qu'avec Ruby, mais vous pouvez toujours l'utiliser pour beaucoup de choses.
Enfin, vous pouvez toujours écrire des scripts Shell. Jusqu'à présent, c'est ce que j'ai fait.
Je suppose que la manière de déployer SVN n'est pas très bonne. Car:
Vous devez ouvrir l'accès SVN pour le monde entier
avoir de nombreux .svn dans les serveurs Web de production
Je pense que Phing pour produire une branche + combine tous les js/css + remplace la config de scène + le téléchargement ssh sur tous les serveurs www est un meilleur moyen.
sSH à 10 serveur www et svn up est également un problème.