Comment commencer à déployer des applications PHP à partir d'un référentiel de sous-version?

https://stackoverflow.com/questions/800294

03-07-2019
|

Question

J'ai entendu la phrase "Déploiement d'applications". ce qui semble beaucoup mieux / plus facile / plus fiable que de télécharger des fichiers modifiés sur un serveur, mais je ne sais pas par où commencer.

J'ai une application Zend Framework sous contrôle de version (dans un référentiel Subversion). Comment puis-je procéder au déploiement de " mon application? Que dois-je faire si j'ai un " uploads " répertoire que je ne veux pas écraser?

Je héberge mon application par l’intermédiaire d’un tiers. Je ne connais donc pas grand-chose autre que FTP. Si cela implique la connexion à mon serveur, veuillez expliquer le processus.

La solution

Le déploiement automatique + l'exécution de tests sur un serveur de transfert est appelé intégration continue. L'idée est que si vous enregistrez quelque chose qui casse les tests, vous en serez immédiatement averti. Pour PHP, vous pouvez consulter Xinc ou phpUnderControl

Cependant, vous ne voudriez généralement pas déployer automatiquement en production. La chose normale à faire est d'écrire des scripts qui automatisent la tâche, mais que vous devez toujours lancer manuellement. Vous pouvez utiliser des frameworks tels que Phing ou d'autres outils de construction pour cela (le choix courant est Capistrano ), mais vous pouvez également combiner quelques scripts de shell. Personnellement, je préfère ce dernier.

Les scripts eux-mêmes peuvent faire différentes choses en fonction de votre application et de votre configuration, mais un processus typique serait:

ssh au serveur de production. Le reste des commandes est exécuté sur le serveur de production, via ssh.

exécuter svn export svn: // chemin / répertoire / repository / tags / RELEASE_VERSION / usr / local / application / releases / TIMESTAMP

arrêter les services (Apache, démons)

exécuter dissocier / usr / local / application / current & amp; & amp; ln -s / usr / local / application / releases / TIMESTAMP / usr / local / application / current

exécuter ln -s / usr / local / application / var / usr / local / application / releases / TIMESTAMP / var

exécuter /usr/local/application/current/scripts/migrate.php

démarrer les services

(En supposant que votre application soit dans / usr / local / application / current )

Autres conseils

Je ne recommanderais pas la mise à jour automatique. Ce n'est pas parce que vos tests unitaires réussissent que votre application fonctionne à 100%. Et si quelqu'un vérifie une nouvelle fonctionnalité au hasard sans aucun nouveau test unitaire, et que la fonctionnalité ne fonctionne pas? Vos tests unitaires existants peuvent réussir, mais la fonctionnalité peut être interrompue de toute façon. Vos utilisateurs peuvent voir quelque chose qui est à moitié fait. Avec le déploiement automatique à partir d'un enregistrement, vous pourriez ne pas remarquer pendant quelques heures si quelque chose le rendait vivant ne devrait pas avoir.

Quoi qu'il en soit, il ne serait pas si difficile de lancer un déploiement automatique si vous le souhaitiez vraiment. Vous aurez besoin d’un point d’arrivée après l’enregistrement, et les étapes à suivre seraient les suivantes:

1) Faites une exportation à partir du dernier enregistrement 2) Exportez le téléchargement sur le serveur de production 3) Décompressez / configurez l’exportation nouvellement téléchargée

J'ai toujours effectué les dernières étapes manuellement. En général, c'est aussi simple que l'exportation SVN, le zip, le téléchargement, le décompression, la configuration, et les deux dernières étapes. Ensuite, j'échange le répertoire de l'application racine avec le nouveau, en m'assurant de conserver l'ancien en tant que sauvegarde, et c'est bien.

Si vous êtes sûr de votre capacité à détecter les erreurs avant qu'elles ne soient automatiquement mises en ligne, vous pouvez envisager d'automatiser cette procédure. Cela me donne quand même des jibblies jibbly.

Voici un excellent article sur l'utilisation de Subversion pour déployer des projets Web & # 8212; cela répond à beaucoup de vos questions.

http://athleticsnyc.com/blog/entry/ on-using-subversion-for-web-projects

Chez ma société webdev, nous avons récemment commencé à utiliser Webistrano , qui est une interface graphique Web du populaire Capistrano. outil.

Nous voulions un outil de déploiement rapide, facile à utiliser, avec une interface centralisée, la responsabilité (quelle version a été utilisée), la restauration des versions précédentes et, de préférence, gratuitement. Capistrano est un outil de déploiement bien connu pour les applications Ruby on Rails, mais il n’est pas centralisé et principalement destiné aux applications Rails. Webistrano s'enrichit d'une interface utilisateur graphique, d'une comptabilité et ajoute un support de base pour le déploiement de PHP (utilisez le type de projet "fichier pur").

Webistrano est lui-même une application Ruby on Rails, que vous installez sur un serveur de développement ou de stockage intermédiaire. Vous ajoutez un projet pour chacun de vos sites Web. A chaque projet, vous ajoutez des étapes, telles que Prod et Dev.

Chaque étape peut avoir différents serveurs sur lesquels déployer, et différents paramètres. Écrivez (ou modifiez) une "recette", qui est un script ruby ??qui indique à capistrano quoi faire. Dans notre cas, je viens d'utiliser la recette fournie et d'ajouter une commande pour créer un lien symbolique vers un répertoire de téléchargement partagé, comme vous l'avez mentionné.

Lorsque vous cliquez sur Déployer, les SSH Webistrano sur vos serveurs distants effectuent une extraction svn du code et de toute autre tâche requise, telle que la migration de bases de données, la création de liens symboliques ou le nettoyage des versions précédentes. Tout cela peut être modifié, bien sûr, après tout, il est simplement scripté.

Nous en sommes très satisfaits, mais il m'a fallu quelques jours pour apprendre et mettre en place, surtout que je ne connaissais pas Ruby et Rails. Néanmoins, je peux fortement le recommander pour une utilisation en production dans les petites et moyennes entreprises, car il s’est avéré très fiable, flexible et nous a permis d’épargner plusieurs fois l’investissement initial. Non seulement en accélérant les déploiements, mais aussi en réduisant les erreurs / accidents.

Ce genre de chose est ce que vous appelleriez "intégration continue". Atlassian Bamboo (coût), Sun Hudson (gratuit) et Cruise Control (gratuit) sont des options populaires (par ordre de préférence) et prennent en charge la gestion de la sortie PHPUnit (car PHPUnit prend en charge la sortie JUnit).

Le déploiement peut être effectué avec un déclencheur post-génération. Comme d’autres personnes sur ce fil, j’exercerais une grande prudence avant de procéder à des déploiements automatisés à l’enregistrement (et à la réussite des tests).

vérifier fredistrano, c’est un clone de capistrano fonctionne très bien (installation un peu déroutante mais après tout fonctionne très bien)

http://code.google.com/p/fredistrano/

Pour gérer les téléchargements, la solution classique consiste à déplacer le répertoire actuel hors de l'espace Web principal, en ne le laissant que pour une nouvelle version à extraire (comme je le fais dans le script ci-dessous), puis en utilisant Apache pour "Alias". le remettre en place dans le cadre du site Web.

Alias /uploads /home/user/uploads/

Cependant, vous avez moins de choix si vous n’avez pas autant de contrôle sur le serveur.

J'ai un script que j'utilise pour déployer un script donné sur les sites dev / live (ils s'exécutent tous les deux sur le même serveur).

#!/bin/sh REV=2410 REVDIR=$REV.20090602-1027 REPOSITORY=svn+ssh://topbit@svn.example.com/var/svn/website.com/trunk IMAGES=$REVDIR/php/i STATIC1=$REVDIR/anothersite.co.uk svn export --revision $REV $REPOSITORY $REVDIR mkdir -p $REVDIR/tmp/templates_c chown -R username: $REVDIR chmod -R 777 $REVDIR/tmp $REVDIR/php/cache/ chown -R nobody: $REVDIR/tmp $REVDIR/php/cache/ $IMAGES dos2unix $REVDIR/bin/*sh $REVDIR/bin/*php chmod 755 $REVDIR/bin/*sh $REVDIR/bin/*php # chmod -x all the non-directories in images find $IMAGES -type f -perm -a+x | xargs -r chmod --quiet -x find $STATIC1 -type f -perm -a+x | xargs -r chmod --quiet -x ls -l $IMAGES/* | grep -- "-x" rm dev && ln -s $REVDIR dev

Je mets le numéro de révision et la date / heure utilisés pour le nom du répertoire extrait. Les modifications au milieu font également que les autorisations sur les images sont acceptables, car elles sont également liées symboliquement à notre serveur d’images dédié.

La dernière chose qui se produit est un ancien lien symbolique ... / website / dev / est lié au nouveau répertoire extrait. La configuration Apache a alors la racine du doc ??de ... / website / dev / htdocs /

Il existe également un lien ... / website / live / htdocs / docroot, et encore une fois, "live" est un autre lien symbolique. C’est mon autre script qui supprimera le lien symbolique actif et le remplacera par tout ce que dev désignera.

#!/bin/sh # remove live, and copy the dir pointed to by dev, to be the live symlink rm live && cp -d dev live

Je ne mets en place une nouvelle version du site que tous les deux jours, vous ne voudrez donc peut-être pas l'utiliser plusieurs fois par jour (mon cache APC n'aimerait pas plus que quelques versions du site), mais pour moi, cela ne pose pas de problème pour mon propre déploiement.

Après 3 ans, j'ai appris un peu sur les meilleures pratiques de déploiement. J'utilise actuellement un outil appelé Capistrano, car il est facile à configurer et à utiliser, et il gère bien de nombreuses valeurs par défaut.

Les bases d'un processus de déploiement automatisé sont les suivantes:

Votre code est prêt pour la production. Il porte donc la version de la version: v1.0.0

En supposant que vous ayez déjà configuré votre script de déploiement, vous l'exécutez en spécifiant la balise que vous venez de créer.

Le script SSH est envoyé à votre serveur de production qui possède la structure de répertoires suivante:

/your-application /shared/ /logs /uploads /releases/ /20120917120000 /20120918120000 <-- latest release of your app /app /config /public ...etc /current --> symlink to latest release Your Apache document root should be set to /your-application/current/public

Le script crée un nouveau répertoire dans le répertoire des versions avec l'heure actuelle. Dans ce répertoire, votre code est mis à jour avec la balise que vous avez spécifiée.

Ensuite, le lien symbolique d'origine est supprimé et un nouveau lien symbolique est créé, pointant vers la dernière version.

Les éléments à conserver entre les versions sont placés dans le répertoire partagé et des liens symboliques sont créés vers ces répertoires partagés.

Cela dépend de votre application et de la solidité des tests.

Où je travaille, tout est archivé dans le référentiel pour être examiné, puis publié.

La mise à jour automatique à partir d'un référentiel ne serait pas une bonne chose pour nous, car nous enregistrons parfois simplement afin que les autres développeurs puissent extraire une version plus récente et y intégrer les modifications.

Pour faire ce dont vous parlez, il faudrait une sorte d’archivage secondaire pour permettre la collaboration entre les développeurs de la zone d’archivage principal. Bien que je ne sache rien à ce sujet ou si c'est même possible.

Des problèmes de création de branches et autres fonctionnalités similaires doivent également être gérés.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow