Quelle est la meilleure façon de publier en toute sécurité une publication de site ?

Question

Alors, d’après votre expérience, quelle est la meilleure solution ?Existe-t-il un moyen sécurisé qui est également scriptable/déclenchable dans un outil d'automatisation de build ?

Modifier:Je dois mentionner qu'il s'agit de Windows/.net et que je vais le déployer sur iis6

Answer 1

Pour certains projets que j'utilise Capistrano pousser pour vivre.Il est construit sur Ruby et rend l'écriture de scripts de déploiement très simple et utilise ssh.

Sur d'autres projets, j'ai une petite application de déploiement qui utilise bash pour effectuer une exportation svn vers un répertoire temporaire, puis la synchroniser sur le serveur live.Vous pouvez faire en sorte que rsync utilise ssh.

Je préfère largement la méthode Capistrano, même si votre projet n'est pas en ruby/rails.

Answer 2

Cela semble être le genre de chose qui pourrait être faite facilement avec SFTP.Jeter un coup d'œil à Mastic (psftp et pscp) ou WinSCP pour Windows, ou rsync et OuvertSSH pour Unix.

Answer 3

@Neall, j'ajouterais un set -e sur la deuxième ligne, car vous ne voulez pas que le site actif soit remplacé si le rsync échoue pour une raison quelconque. set -e provoque la fermeture du script si l'une de ses commandes échoue.

Modifier:Le set -e devrait être la première chose dans le script, juste après #!/bin/bash.

Answer 4

Faites une copie du répertoire de votre site en direct, utilisez rsync pour mettre à jour cette copie avec votre dernière version, puis renommez les répertoires live et mis à jour afin que la version mise à jour soit désormais active.

En bash :

#!/bin/bash

set -e
cp -R /var/livesite /var/newversion
rsync user@devserver:/var/readytogolive /var/newversion
mv /var/livesite /var/oldlivesite
mv /var/newversion /var/livesite

Alto!

Modifier:@Ted Percival - C'est une bonne idée.Je ne connaissais même pas "set -e".Script mis à jour.Modifier:mis à jour à nouveau à la suggestion de Ted (même si je pense que cela fonctionnerait toujours si la commande cp échouait, et si cp échoue, vous aurez probablement des problèmes plus graves.)

Answer 5

J'appuie la recommandation pour Capistrano, mais si vous recherchez une solution basée sur une interface graphique, vous pouvez essayer le Webistrano l'extrémité avant.Sémantique de déploiement et de restauration propre, basée sur SSH, ainsi que script et extensibilité faciles via Ruby.

Answer 6

Vous pouvez toujours écrire une petite application client/serveur qui chiffre à la source, transmet les fichiers, puis décrypte à destination.C'est un peu de travail, mais probablement une somme insignifiante.Et c'est scriptable tant que votre outil d'automatisation prend en charge l'exécution de quelque chose dans le système de fichiers (ce que je pense que tous font).

Le seul inconvénient est que vous ne pourrez peut-être pas obtenir de messages d'erreur significatifs en cas d'échec dans votre environnement d'intégration sans un peu plus de travail de votre part (bien qu'en fonction de votre configuration, cela puisse être aussi simple que d'envoyer des messages d'erreur à la sortie standard).

Answer 7

hm, ici, nous utilisons un "serveur" intermédiaire à des fins de tests sur l'environnement réel (en fait, c'est un hôte virtuel Apache sur le serveur de production) et fusion araxis (un outil de comparaison de fichiers ligne par ligne très intelligent) pour synchroniser le développement et la préparation.

une fois testé, juste ;remplacez les fichiers sur la racine Web de production :)

/mp

Answer 8

Dans le cadre d'un travail indépendant que j'ai effectué, nous avons créé trois environnements distincts.

• Un serveur de développement qui exécutait des builds continus à l'aide de CruiseControl.Tout enregistrement déclencherait une build.Des tests d'assurance qualité ont été effectués ici.
• Un serveur de test sur lequel les tests d'acceptation des utilisateurs ont été effectués.
• Production.

Le flux de travail était le suivant :

1. Le développeur enregistre les modifications apportées à SourceControl.
2. CruiseControl construit et déploie la version sur Dev.
3. Le développeur est soumis à un contrôle qualité
4. Après avoir réussi le contrôle qualité, un script robocopy est exécuté pour déployer la version de développement sur Test.
5. Le test est UAT
6. Une fois le test réussi, un script robocopy est exécuté pour déployer le test sur PRD.