Quelle est votre stratégie de déploiement php préférée?

Question

Je commence un nouveau projet en PHP et j'aimerais obtenir quelques retours d'autres développeurs sur leur stratégie préférée pour le déploiement PHP. J'aimerais automatiser les choses un peu, de sorte qu'une fois que les modifications sont validées, elles peuvent être rapidement transférées à un serveur de production.

J'ai de l'expérience avec des déploiements à l'aide de Capistrano avec Ruby ainsi que certains de base de scripts shell.

Avant de plonger la tête la première sur mon propre il serait formidable d'entendre comment les autres ont abordé ce problème dans leurs projets.

De plus amples informations

Actuellement, les développeurs travaillent sur les installations locales du site et de valider les modifications apportées à un dépôt subversion. Les premiers déploiements sont faites par l'exportation d'une version marquée depuis le svn et le téléchargement que pour le serveur.

Des changements supplémentaires sont généralement fait à l'unité manuellement en téléchargeant les fichiers modifiés.

Answer 1

Pour PHP, SVN avec Phing scripts de compilation sont la voie à suivre. Phing est similaire à la FOURMI, mais il est écrit en PHP, ce qui le rend beaucoup plus facile pour les développeurs PHP à modifier pour répondre à leurs besoins.

Notre routine de déploiement est comme suit:

• Tout le monde se développe sur le même serveur local au travail, chaque développeur a un checkout sur sa machine à de retour à la maison.
• S'engage déclencher un post-commit hook qui met à jour un serveur de test.
• Les Tests sont a couru sur le serveur de test, si ils passent.
• Phing construire script est exécuté:
• Prend vers le bas d'un serveur de production, de commutation du domaine "en construction" à la page
• Fonctionne SVN update sur la production de caisse
• Fonctionne schéma deltas script
• Exécute les tests
• Si les tests échouent - exécuter le script de restauration
• Si les tests passent, serveur de voies de retour à la production caisse

Il y a aussi phpUnderControl, qui est un serveur d'Intégration Continue. Je ne trouve pas ça très utile pour des projets web, pour être honnête.

Answer 2

Je suis actuellement le déploiement de PHP à l'aide de Git. Un simple git push production est tout ce qui est nécessaire pour mettre à jour mon serveur de production avec la dernière version de Git. Il est facile et rapide parce que Git est assez intelligent pour envoyer seulement les différences et non de l'ensemble du projet au cours de nouveau. Il permet également de maintenir une copie redondante du référentiel sur le serveur web en cas de panne matérielle sur ma fin (même si j'ai aussi pousser à GitHub pour être sûr).

Answer 3

Nous utilisons Webistrano, une interface web de Capistrano, et sont très heureux avec elle.

Webistrano permet multi-étape, multi-environnement déploiements de SVN, GIT et les autres. Il a intégré dans la restauration, le soutien pour séparer les rôles de serveur web, db, app, etc., et se déploie en parallèle. Il vous permet de remplacer les paramètres de config sur plusieurs niveaux, comme par étape, et consigne les résultats de tous les déployer, éventuellement de diffusion.

Même si Capistrano et Webistrano sont des applications Ruby, la syntaxe du déploiement de "recettes" est facile et assez puissant pour comprendre pour n'importe quel programmeur PHP. À l'origine, Capistrano a été construit pour Ruby on Rails des projets, mais peut facilement accueillir des projets PHP.

Une fois configuré, il est même assez facile à être utilisé par des non-programmeurs, tels que les testeurs du déploiement d'une mise en scène de la version.

De fournir le plus rapide de déployer possible, nous avons installé la fast_remote_cache méthode, qui met à jour un svn travail de copie en cache sur le serveur distant, puis les liens du résultat.

Answer 4

J'utilise Apache Ant à déployer pour différentes cibles (dev, QA et de vivre). Ant est conçu pour Java de déploiement, mais il fournit un assez utile le cas général la solution pour le déploiement des fichiers arbitraires.

La syntaxe de la build.xml le fichier est assez facile à apprendre - vous de définir des cibles et de leurs dépendances qui s'exécutent lorsque vous appelez la fourmi programme sur la ligne de commande.

Par exemple, j'ai des objectifs pour les dev, QA et de vivre, chaque de ce qui dépend de la cvsbuild cible qui récupère la dernière version de tête de notre serveur CVS, copie les fichiers appropriés dans le répertoire de construction (à l'aide de la fileset tag), puis rsyncs le répertoire de construction du serveur approprié. Il y a quelques bizarreries à apprendre, et la courbe d'apprentissage n'est pas totalement plat, mais j'ai fait de cette façon pendant des années sans aucun problème, donc je le recommande pour votre situation, mais je suis curieux de ce que d'autres réponses, je vais voir sur ce fil.

Answer 5

Je fais les choses manuellement à l'aide de Git. Un référentiel pour le développement, qui reçoit git push --mirror'ed à un public de pensions, et le serveur live est un troisième repo sorti de cette. Cette partie, je pense que c'est le même que votre propre configuration.

La grande différence, c'est que j'utilise des branches pour presque tous les changement que je suis en train de travailler sur (j'ai environ 5), et ont tendance à retourner en arrière et en avant entre eux. La branche master à ne pas avoir changé directement à l'exception de la fusion d'autres branches.

Je lance le serveur live direct de la branche master, et quand j'en ai fini avec une autre branche et prêt à fusionner, flip le serveur à cette branche pendant un certain temps. En cas de casse, de le remettre à maître ne prend que quelques secondes. Si cela fonctionne, il est fusionné en maître et le live de code est mis à jour. Je suppose que d'une analogie de cette SVN serait d'avoir deux copies de travail et pointant vers le live via un lien symbolique.