Question

Je commence un nouveau projet en PHP et j'aimerais connaître l'avis 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 rapidement être migrées vers un serveur de développement ou de production.

J'ai de l'expérience dans les déploiements avec Capistrano avec Ruby, ainsi que dans les scripts shell de base.

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.

Informations complémentaires

Actuellement, les développeurs travaillent sur des installations locales du site et valident les modifications apportées à un référentiel de sous-version. 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 à la pièce en téléchargeant manuellement les fichiers modifiés.

Était-ce utile?

La solution

Pour PHP, les réseaux sociaux avec les scripts de génération Phing sont la solution. Phing est similaire à ANT , mais il est écrit en PHP, ce qui permet aux développeurs PHP de le modifier plus facilement. 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 un paiement sur son ordinateur.
  • Les validations déclenchent un hook post-validation 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é:
  • arrête le serveur de production et remplace le domaine par un "en construction". page
  • Exécute la mise à jour SVN lors de la validation de la production
  • Exécute le script de deltas de schéma
  • Lance les tests
  • Si les tests échouent - exécutez le script d'annulation
  • Si les tests réussissent, le serveur renvoie à la vérification de la production

Il existe également un 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.

Autres conseils

Je déploie actuellement PHP avec Git . Une simple production git push suffit pour mettre à jour mon serveur de production avec la dernière copie de Git. C'est facile et rapide, car Git est suffisamment 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 les annulations, prend en charge des rôles de serveur distincts tels que Web, base de données, application, etc., et se déploie en parallèle. Il vous permet de remplacer les paramètres de configuration sur 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 simple et suffisamment puissante pour être comprise par tout programmeur PHP. A l’origine, Capistrano avait été construit pour les projets Ruby on Rails, mais s’adaptait facilement aux projets PHP.

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.

Afin de fournir le déploiement le plus rapide possible, nous avons installé la méthode fast_remote_cache , qui met à jour un svn cache de copie de travail sur le serveur distant, puis associe en dur le résultat.

J'utilise Apache Ant pour effectuer le déploiement sur différentes cibles (dev, QA et live). Ant est conçu pour fonctionner avec le déploiement Java, mais il fournit une solution 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, qui dépendent chacune 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 sujet.

Je fais les choses manuellement en utilisant Git. Un référentiel de développement, qui obtient git push --mirror , est envoyé à un référentiel public, et le serveur actif est un troisième référentiel tiré de cela. Je suppose que cette partie est la même que votre propre configuration.

La grande différence, c’est que j’utilise des branches pour presque tous les changements sur lesquels je travaille (j’en ai actuellement environ 5) et que j’ai tendance à basculer entre elles. La branche principale ne doit pas être modifiée directement, sauf pour fusionner d'autres branches.

J'exécute le serveur actif 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.

Je sais que Phing a été mentionné à quelques reprises maintenant, mais j'ai eu beaucoup de chance avec < a href = "http://www.phpundercontrol.org/about.html" rel = "nofollow noreferrer"> phpUnderControl . Pour nous nous

  1. Extraire des copies individuelles de branches sur des ordinateurs locaux
  2. Les branches sont testées puis fusionnées dans le tronc
  3. Les validations vers le tronc sont automatiquement construites par phpUnderControl, exécute des tests et construisent toute la documentation, applique les deltas de la base de données
  4. Le coffre est soumis à des tests de qualité puis fusionné dans notre branche Stable
  5. Encore une fois, phpUnderControl construit automatiquement Stable, exécute des tests, 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 insère les fichiers. La commande rsync est appelée à la main afin de s’assurer que quelqu'un regarde la promotion.

une alternative aux scripts de déploiement faits 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 généralement un excellent outil pour la surveillance, la vérification des journaux, etc. Il existe également l’avantage de déployer bonne configuration connue qui sera mise à jour au fil du temps (un mal de tête en moins pour vous).

La PaaS que je recommanderais est dotCloud , en plus de PHP ( consultez leur quickstart PHP ), il peut également déployer MySQL, MongoDB et toute une série de services supplémentaires. Il propose également des avantages tels que le déploiement sans interruption, la restauration instantanée, la prise en charge complète de SSL et de WebSocket, etc. Il existe également un niveau gratuit qui est toujours agréable:)

Bien sûr, je suis légèrement biaisé depuis que je travaille là-bas! Pagodabox et Orchestra (qui font maintenant partie de Engine Yard) méritent d’être testés, en plus de dotCloud.

J'espère que ça aide!

Salomon

Le fait de transférer automatiquement et à l'aveuglette des modifications d'un référentiel vers des serveurs de production semble dangereux. Que se passe-t-il si votre code engagé contient un bogue de régression, de sorte que votre application de production devienne glitch?

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, comme je le fais de manière manuelle, par exemple. scp.

Je suis arrivé trop tard à la fête, mais je pensais partager nos méthodes. Nous utilisons Phing avec Phingistrano , qui fournit une fonctionnalité de type Capistrano à Phing via des fichiers de génération prédéfinis. C’est très cool, mais cela 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 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 port de rake (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 consiste à 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.

http://controltier.org/wiki/Main_Page

nous allons l'utiliser pour les déploiements multi-serveurs & amp; maintenance.

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.

À la place, les crochets de sous-version 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 lui-même, 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.

Dans mon travail, mon équipe et moi-même avons mis au point un substitut orienté Phing pour le déploiement de capistrano et nous avons également intégré certains des atouts disponibles dans Phing tels que PHPUnit testing, phpcs et PHPDocumentor. Nous en avons fait un 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 n'importe lequel de nos différents environnements (mise en scène, test, production, etc.).

Avec les scripts de construction 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 publier de lien pour le moment car le référentiel 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 des questions 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. Parce que:

Vous devez ouvrir l'accès SVN pour le monde entier

ont beaucoup de .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 un meilleur moyen.

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

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top