Comment faire un déploiement pour l'application php

Question

Je développe actuellement une application php pour une organisation caritative et je suis maintenant dans la phase de définition des pratiques de déploiement.

Notre application utilise à la fois Zend Framework et Doctrine. L'application sera déployée sur différents serveurs, chacun avec un fichier de configuration différent. Les machines sont à la fois Windows et Linux (mais toutes avec Apache et PHP 5.2+).

La source est disponible dans un dépôt Subversion et nous voulons construire et stocker nos paquets sur un serveur Linux. De préférence, nous souhaitons que le processus de mise à jour soit aussi simple qu'une commande de mise à jour dans le répertoire de l'application, où la commande update met également à jour la base de données (avec les scripts de doctrine) et assure les dépendances des frameworks. Cette commande de mise à jour doit être une commande sur la machine (nous ne pouvons pas y entrer). De préférence, nous avons la possibilité de télécharger une nouvelle version ou de fournir une archive tar déjà téléchargée avec une nouvelle version. (mais seulement le téléchargement ou seulement l'archive est également correct)

Les paquets avec des installations et des mises à jour (nouvelles versions) sont également de préférence construits par une commande simple.

J'ai lu un peu sur phar's, pear, phing mais je n'ai aucune idée de la meilleure façon de le faire. Un serveur d'intégration continue n'est pas vraiment nécessaire, mais je pense au déploiement automatique des environnements de test après la construction d'une version.

Initialement, seule la mise à jour de l'application php doit être très facile, en remplissant initialement un fichier de configuration lorsque l'installation peut être effectuée manuellement.

Answer 1

Vous avez dit que vous avez un claster. Nous sommes dans la même position et nous utilisons ZF et Doctrine. Voici comment nous avons résolu le problème:

<?xml version="1.0" encoding="UTF-8"?> 
<project name="yourprojectname" basedir="."> 

<target name="deploy" depends="apply-deltas,update-app01,update-app02"> 

</target> 

<target name="update-app01"> 

    <sshexec host="app01" 
    username="yourusername" 
    password="yourpassword" 
    trust="true" 
    command="cd path/to/root/directory &amp;&amp; 
     svn update &amp;&amp; 
     php cmd/clear_cache.php 
     "/> 

</target> 

<target name="update-app02"> 

    <sshexec host="app02" 
     username="yourusername" 
     password="yourpassword" 
     trust="true" 
     command="cd path/to/root/directory &amp;&amp; 
     svn update &amp;&amp; 
     php cmd/clear_cache.php 
     "/> 

</target> 

    <target name="apply-deltas" depends="liquibase-prepare"> 
    <updateDatabase 
      changeLogFile="${db.changelog.file}" 
      driver="${database.driver}" 
      url="${database.url}" 
      username="${database.username}" 
      password="${database.password}" 
      promptOnNonLocalDatabase="${prompt.user.if.not.local.database}" 
      dropFirst="false" 
      classpathref="classpath" > 
      <changeLogProperty name="table.name" value="ant_param_table"/> 
    </updateDatabase> 
    </target> 


<target name="liquibase-prepare"> 
    <path id="classpath"> 
    <fileset dir="${basedir}/libNoPackage"> 
     <include name="**/*.jar" /> 
    </fileset> 
    </path> 

    <taskdef resource="liquibasetasks.properties"> 
     <classpath refid="classpath"/> 
    </taskdef> 
    </target> 

</project> 

Ceci est loin d'être idéal mais cela fonctionne très bien pour nous. J'espère que cela pourra aider.

Liens:

Apache Ant

LiquiBase

Si vous avez des questions s'il vous plaît laissez-moi savoir si je peux mettre à jour le answer.t

Answer 2

Peut-être parfois plus simple approche fonctionne mieux . Si vous gardez des versions stables simplement étiquetées dans le repo svn, vous pouvez simplement écrire un script batch/bash pour télécharger la dernière révision tout en sauvegardant à l'ancienne sans intervention de l'utilisateur - vous pouvez également exécuter les scripts requis de cette manière. Une autre alternative est d'écrire une interface simple en PHP, mais cela dépend de la simplicité.

Answer 3

Je commencerais par faire de la racine de l'application des différents serveurs une copie de travail SVN. Vous pouvez ajouter des règles mod_rewrite (ou IIRF ASAPI filters for IIS) pour vous assurer que les utilisateurs ne peuvent pas directement adresser vos répertoires .svn. Ensuite, la mise à jour vers la dernière source peut être aussi simple qu'une mise à jour SVN. Pour les besoins de la mise à jour de votre base de données, je conserverais les scripts de modification de la base de données également dans SVN. Vous aurez probablement besoin d'envelopper la mise à jour SVN dans un script batch/shell afin d'effectuer les mises à jour de la base de données après le téléchargement des scripts.

Pour la gestion du changement sur les serveurs en direct, j'aurais aussi leurs copies de travail pas de tronc, mais une branche de publication. Vous pouvez fusionner le tronc dans la branche de publication lorsque vous êtes prêt pour une version. Cela vous permettra de tester le déploiement et de vous assurer qu'il est solide avant de l'exécuter sur les serveurs live. Cela a aussi l'effet secondaire de vous donner une belle réplique des versions du site au cas où vous auriez besoin de repérer les problèmes après le lancement. Enfin, en fonction de l'intensité et du calendrier de ces mises à jour, vous souhaiterez peut-être que votre script de mise à jour retourne un commutateur "en cours de maintenance" afin que les utilisateurs reçoivent temporairement un message approprié plutôt qu'un site endommagé.

Answer 4

Benjamin Eberlei a publié un article il y a quelques semaines intitulé Trying a Two Step PEAR/PHAR approach to develop and deploy. Il décrit une procédure très intéressante et élégante pour déployer une application PHP.

Answer 5

J'ai utilisé subversion comme un outil de déploiement pour un excellent effet. Utilisez svn update sur tous vos serveurs de production, ou utilisez phing. (Ou utilisez phing pour svn update, pair.)

Facilite les restaurations et les sauvegardes. N'oubliez pas de supprimer l'accès à tous les répertoires .svn.

Answer 6

De toute façon, je gérerais vos builds avec phing ou quelque chose de similaire. Laissez-le exécuter vos tests, générer des documents, construire et publier votre paquet/tarball.

En ce qui concerne la distribution, vous pouvez run your own PEAR server. La logique ici est que vous avez dit que vous voulez que les utilisateurs tirent des mises à jour, vous avez des utilisateurs Windows et Linux, et vous voulez gérer les dépendances pour eux. PEAR devrait être capable de gérer tout ça avec une seule commande.

Cela dit, je voudrais aller avec la chose la plus simple qui fonctionne et convient à vos utilisateurs. Cela pourrait être juste une archive disponible via HTTP et un petit script de mise à niveau PHP (ou une cible phing.)

Fournir un moyen simple de revenir à une version précédente. Avec le code/configuration, vous pouvez simplement garder une copie. Avec DB, utilisez les migrations (ce que vous avez l'impression de faire déjà).