Quelle est votre stratégie de déploiement PHP préférée? [fermé]

Je commence un nouveau projet en PHP et j'aimerais avoir des commentaires d'autres développeurs sur leur stratégie préférée pour le déploiement de PHP. J'aimerais automatiser un peu les choses pour qu'une fois les modifications validées, elles puissent être rapidement migrées vers un serveur de développement ou de production.

J'ai de l'expérience avec les déploiements utilisant Capistrano avec Ruby ainsi qu'avec des scripts shell de base.

Avant de plonger la tête la première par moi-même, ce serait formidable d'entendre comment les autres ont abordé cela dans leurs projets.

Informations complémentaires

Actuellement, les développeurs travaillent sur les installations locales du site et commettent les modifications dans un référentiel subversion. Les déploiements initiaux sont effectués en exportant une version balisée de svn et en la téléchargeant sur le serveur.

Les modifications supplémentaires sont généralement apportées au coup par coup en téléchargeant manuellement les fichiers modifiés.

Pour PHP, SVN avec les scripts de construction Phing est la voie à suivre. Phing est similaire à ANT mais est écrit en PHP, ce qui permet aux développeurs PHP de modifier beaucoup plus facilement pour leurs besoins.

Notre routine de déploiement est la suivante:

• Tout le monde 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 intermédiaire.
• Les tests sont exécutés sur le serveur intermédiaire, s'ils réussissent - continuez.
• Le script de construction Phing est exécuté:
• Arrête le serveur de production, basculant le domaine vers une page "En construction"
• Exécute la mise à jour SVN lors de la vérification de la production
• Exécute le script deltas de schéma
• Exécute des tests
• Si les tests échouent - exécutez le script de restauration
• Si les tests réussissent, le serveur retourne à la caisse de production

Il y a aussi phpUnderControl , qui est un serveur d'intégration continue. Je n'ai pas trouvé cela très utile pour les projets web pour être honnête.

Je déploie actuellement PHP avec Git . Une simple production git push est tout ce dont j'ai besoin pour mettre à jour mon serveur de production avec la dernière copie de Git. C'est facile et rapide parce que Git est assez intelligent pour ne renvoyer que les diffs et non tout le projet. Cela permet également de conserver une copie redondante du référentiel sur le serveur Web en cas de panne matérielle de mon côté (bien que je pousse également vers GitHub pour être sûr).

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 dispose d'une prise en charge intégrée de la restauration, de 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 à plusieurs niveaux, par exemple par étape, 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 des «recettes» de déploiement est assez simple et puissante à comprendre pour tout programmeur PHP. À l'origine, Capistrano a été conçu pour les projets Ruby on Rails, mais s'adapte facilement aux projets PHP.

Une fois configuré, il est même assez simple pour être utilisé par des non-programmeurs, tels que des 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 de copie de travail svn sur le serveur distant, puis lie en dur le résultat.

J'utilise Apache Ant pour déployer sur différentes cibles (dev, QA et live). Ant est conçu pour fonctionner pour le déploiement Java, mais il fournit une solution de cas général assez utile pour déployer des 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, dont 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 (en utilisant la balise fileset), puis rsynchronise 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 de cette façon depuis des années sans problème, alors je le recommande pour votre situation, même si je suis curieux de savoir quelles autres réponses je 'll voir sur ce fil.

Je fais des choses manuellement en utilisant Git. Un référentiel pour le développement, qui est git push --mirrortransféré vers un référentiel public, et le serveur live est un troisième référentiel tiré de cela. Cette partie, je suppose, 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 en ce moment) et que j'ai tendance à basculer entre elles. La branche principale n'est pas modifiée directement, sauf pour la fusion d'autres branches.

Je lance le serveur en direct directement à partir de la branche principale, et lorsque j'en ai terminé avec une autre branche et que je suis prêt à la fusionner, retournez le serveur vers cette branche pendant un moment. S'il casse, le remettre au maître prend quelques secondes. Si cela fonctionne, il est fusionné dans master et le code en direct est mis à jour. Je suppose qu'une analogie de ceci dans SVN serait d'avoir deux copies de travail et de pointer vers celle en direct via un lien symbolique.

je connais Phing a été mentionné à quelques reprises maintenant, mais j'ai eu beaucoup de chance avec phpUnderControl . Pour nous nous

1. Consultez des copies individuelles des succursales sur les machines locales
2. Les branches sont testées puis fusionnées dans Trunk
3. Les commits to Trunk sont automatiquement construits par phpUnderControl, exécute les tests et construit toute la documentation, applique les deltas de base de données
4. Le tronc est soumis à des tests de qualité, puis fusionné dans notre branche stable
5. Encore une fois, phpUnderControl crée automatiquement Stable, exécute des tests et génère de la documentation et met à jour la base de données
6. Lorsque nous sommes prêts à passer à la production, nous exécutons un script rsync qui sauvegarde la production, met à jour la base de données, puis pousse les fichiers vers le haut. La commande rsync est invoquée manuellement afin que nous nous assurions que quelqu'un regarde la promotion.

une alternative aux scripts de déploiement maison consiste à déployer sur une plateforme en tant que service qui résume une grande partie de ce travail pour vous. Un PaaS proposera généralement son propre outil de déploiement de code, ainsi que la mise à l'échelle, la tolérance aux pannes (par exemple, ne pas tomber en panne en cas de panne du matériel), et généralement une excellente boîte à outils pour la surveillance, la vérification des journaux, etc. bonne configuration connue qui sera tenue à jour au fil du temps (un mal de tête en moins pour vous).

Le PaaS que je recommanderais est dotCloud , en plus de PHP ( voir leur quickstart PHP ), il peut également déployer MySQL, MongoDB et tout un tas de services supplémentaires. Il a également de bons avantages comme le déploiement sans temps d'arrêt, la restauration instantanée, la prise en charge complète de SSL et de websocket, etc. Et il y a un niveau gratuit qui est toujours agréable :)

Bien sûr, je suis un peu partial depuis que j'y travaille! En plus de dotCloud, d'autres options à vérifier sont Pagodabox et Orchestra (qui font maintenant partie d'Engine Yard).

J'espère que cela t'aides!

Salomon

Le fait que vous preniez automatiquement et aveuglément les modifications d'un référentiel vers des serveurs de production semble dangereux. Que faire si votre code validé contient un bogue de régression, si bien que votre application de production devient problématique?

Mais, si vous voulez un système d'intégration continue pour PHP, je suppose que Phing est le meilleur choix pour PHP. Je ne l'ai pas testé moi-même, cependant, car je bourre de manière manuelle, par exemple, scp.

Je suis bien en retard à la fête, mais je pensais partager nos méthodes. Nous utilisons Phing avec Phingistrano , qui fournit des fonctionnalités de type Capistrano à Phing via des fichiers de construction pré-construits. C'est très cool, mais ne fonctionne que si vous utilisez Git pour le moment.

J'ai une copie de travail d'une branche de version 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 mettre le site hors ligne.

Phing est probablement votre meilleur pari, si vous pouvez supporter la douleur des fichiers de configuration xml. Le framework Symfony a son propre port de rake (pake), qui fonctionne assez bien, mais est plutôt étroitement couplé au reste de Symfony (bien que vous puissiez probablement les séparer).

Une autre option consiste à utiliser Capistrano. De toute évidence, il ne s'intègre pas aussi bien avec PHP que avec Ruby, mais vous pouvez toujours l'utiliser pour beaucoup de choses.

Enfin, vous pouvez toujours écrire des scripts shell. Jusqu'ici, c'est ce que j'ai fait.

http://controltier.org/wiki/Main_Page

nous allons l'utiliser pour les déploiements et la maintenance multi-serveurs.

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 automatiquement des scripts de migration de base de données.

Au lieu de cela, les hooks de subversion sont utilisés pour 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 exécuté des tests et vérifié que tout fonctionnera. Pour le déploiement lui-même, j'utilise un Makefile sur mesure qui utilise rsync pour transférer des fichiers. Le Makefile peut également exécuter les scripts de migration sur le serveur distant, mettre en pause / reprendre les serveurs Web et de base de données.

À mon travail, mon équipe et moi-même avons développé un remplacement orienté Phing pour le déploiement de capistrano et nous avons également incorporé certains des goodies disponibles dans phing comme les tests PHPUnit, phpcs et PHPDocumentor. Nous en avons fait un dépôt git qui peut ê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 l'un de nos nombreux environnements (mise en scène, test, production, etc.).

Avec les scripts de construction phing, vous pouvez les exécuter manuellement à partir de la ligne de commande, et j'ai également réussi à automatiser les routines de construction / déploiement avec Hudson et maintenant Jenkins ci.

Je ne peux pas publier de liens pour le moment car le dépôt n'est pas encore public, mais on m'a dit que nous allions parfois l'ouvrir bientôt, alors n'hésitez pas à me contacter si vous êtes intéressé ou si vous avez toute question sur l'automatisation de votre déploiement avec phing et git.

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 + combiner tous les js / css + remplacer la configuration de l'étape + le téléchargement ssh sur tous les serveurs www est une meilleure façon.

ssh à 10 serveur www et svn up est également un problème.