web-dev-qa-db-fra.com

Pouvez-vous recommander des moyens de gérer le déploiement de code sur un serveur Web basé sur Linux?

J'ai toujours utilisé un script bash très simple pour déployer du code. Je n'utilise plus Subversion pour Mercurial, mais je ne pense pas que le logiciel de contrôle des révisions soit important pour le déploiement.

Quelles sont les meilleures façons de le faire?

#!/bin/sh
date=`date +%Y%m%d_%H%M%S`
tar -zcvf app-dir-$date.tar.gz app/dir 
tar -zcvf app-templates-$date.tar.gz app/templates
tar -zcvf app-media-$date.tar.gz app/media
svn export http://example.com/somepath/trunk hh/ --force
web-hostinglinuxsite-deployment
7
citadelgrad

J'utilise Mercurial pour tout gérer , y compris mes pages HTML statiques. Cela rend la vie vraiment très facile pour moi.

Les avantages incluent

  • Toutes les offres de contrôle de version des avantages (annulations, balises jalons, etc.)
  • Être capable de cloner votre site rapidement
  • Vous avez toujours une sauvegarde/copie locale en état de fonctionnement
  • Facile à synchroniser si vous avez tendance à apporter des modifications en place (sur place, sur le serveur)
  • La plupart des hôtes partagés (si vous en avez un) ne craignent pas de l'installer

Avertissement, j'ai écrit le tutoriel. Oui, le type de VCS que vous utilisez importe dans une certaine mesure. Par exemple, je ne voudrais pas utiliser quelque chose dans ce scénario où je ne pourrais pas valider localement et faire un gros push/update. Cela me force simplement à regrouper trop de changements potentiellement problématiques en un seul engagement.

Je pourrais le faire avec Subversion, et je ne suis pas du tout en train de frapper SVN. Je pense juste que Mercurial est un outil bien meilleur pour le problème que vous essayez de résoudre.

Je pense que vous ne devriez pas avoir à contourner vos outils à moins que vous n’ayez pas le choix. Faire ainsi sorte de défaire le but de les avoir, et vous avez le choix :)

5
Tim Post

Outre les excellentes suggestions contenues dans les autres réponses, vous voudrez peut-être déterminer s'il est important pour vous de faire une mise à jour atomique.

Sur mon serveur FreeBSD, j'accomplis cela à travers deux mécanismes:

  • Versionnant toutes mes ressources statiques. (Exemple: http://static.example.com/images/logo.1.png ou http://static.example.com/style/main.3.css). Cela me permet de svn update le site statique directement avant la mise à jour du site dynamique, sans que les utilisateurs voient les nouveaux fichiers dans les anciennes pages.

  • Gestion des versions de l'ensemble du site Web dynamique. Dans mon cas, la racine de mon document pointe vers un lien symbolique. Ma stratégie est de mettre en place la nouvelle version de la production, puis avec une seule commande Push it live. .g. quelque chose comme ça:

    cp -Rp www.site1.com.1 www.site1.com.2 (ou svn checkout)

    svn update site1.com.2 (peut avoir besoin d'un svn switch en premier)

    ln -sf site1.com.2 www.site1.com (déplacer de manière atomique les modifications apportées à la production)

Cela garantit qu'aucun de mes utilisateurs ne verra une page à moitié cuite. Ils verront l'ancienne version si elle est encore dans leur cache ou la nouvelle.

Cette stratégie ne fonctionne bien que si vous ne mélangez pas le contenu téléchargé par l'utilisateur avec votre site dynamique.

1
JasonBirch

Nous utilisons ant's tâche scp , avec le sélecteur modifié . Cela signifie que vous venez de mettre à jour les fichiers qui ont été modifiés depuis le dernier téléchargement. Malheureusement, le sélecteur modifié semble être conçu uniquement pour un usage personnel, pas pour le partage avec les membres de l'équipe. Le fichier cache.properties contient des noms de chemin d'accès au répertoire de travail de l'utilisateur. Nous avons écrit plusieurs cibles pour fourmi afin de modeler le fichier cache.properties dans un format pouvant être partagé par les développeurs, puis repris dans le format souhaité par ant. Le format varie également entre un environnement Windows et un environnement GNU/Linux.

0
Don Kirkby

N’est-il pas utile d’utiliser le contrôle de version pour ne pas avoir à s’occuper de la sauvegarde du site avant de publier une mise à jour?

Si c'est fait correctement, un svn update (ou son équivalent) devrait suffire, et si c'est une erreur, restaurez-le à un commit précédent? C'est ce que nous faisons de toute façon. Validez toutes les modifications, svn update le serveur de transfert, si tout va bien, alors svn update le serveur actif.

0
Mark Henderson