9
votes

Meilleure pratique pour mettre à jour un site Web en direct en cours d'exécution sur IIS

Actuellement, lorsque nous avons des mises à jour que nous souhaitons déployer sur notre site Web en direct, nous exécutons un fichier .bat qui copie toute la structure de dossiers de notre environnement de développement vers les serveurs en direct. Ceci remplace le dossier que le répertoire virtuel pointe avec le nouveau nouveau mis à jour. Ceci est fait pendant que le serveur et IIS sont en direct et manifestement lorsque les utilisateurs accèdent au site Web.

Nous obtenons occasionnellement des erreurs causées par des fichiers ou des dossiers devenant «verrouillés» immédiatement après une mise à jour, et la seule option est généralement d'arrêter IIS ou de redémarrer le serveur. Nous devinons que ce "verrouillage" est causé par le fichier .bat tente de remplacer un fichier lorsqu'il est utilisé par IIS.

Quelqu'un d'autre a-t-il déjà expérimenté cela et / ou que recommanderiez-vous comme le meilleur moyen de mettre à jour un site Web en direct à la volée avec un minimum de temps d'arrêt (c'est-à-dire pas de temps d'arrêt).

Merci.


1 commentaires

Si vous ne pouvez pas avoir de temps d'arrêt, la meilleure chose à faire est d'avoir une autre copie du serveur en cours d'exécution que vous pouvez détourner les utilisateurs lorsque vous souhaitez mettre à jour le primaire. Ensuite, vous renvoyez vos utilisateurs à la première fois après la mise à jour. Vous pouvez utiliser le serveur d'état assis sur un autre serveur pour vous assurer que tout état de session est maintenu lorsqu'il passe de l'une à l'autre. Nous expérimentons actuellement le cadre Web de Microsoft, qui semble très bien faire ce genre de chose.


3 Réponses :


5
votes

Achetez un deuxième serveur Web, achetez un équilibreur de chargement. Mark 1 Server hors ligne, mise à niveau, ramener en ligne. Mark Server 2 hors ligne, mise à niveau, ramener en ligne.


2 commentaires

Merci pour la réponse, nous avons déjà la configuration que vous décrivez. Cependant, les serveurs exécutent de nombreuses applications Web (10+) et nos développeurs gagnent de nombreuses mises à jour par jour afin que nous souhaitions rendre le processus de mise à jour aussi simple et rapide que possible. D'où la raison pour laquelle la méthode de fichier simple .bat a bien fonctionné jusqu'à présent.


Beaucoup de mises à jour du codeBase par jour? Ce n'est pas bon. Si vous faites simplement des modifications HTML ou de balisage dans les pages ASPX elles-mêmes, vous devriez être en mesure de mettre à jour les serveurs sans avoir à les mettre hors ligne. Si vous mettez cependant à jour le code derrière le code ou le code du contrôleur qui souvent .......



5
votes

republié comme une réponse plutôt qu'un commentaire, avait un moment stupide là-bas!

Si vous ne pouvez pas avoir de temps d'arrêt, la meilleure chose à faire est d'avoir une autre copie du serveur en cours d'exécution que vous pouvez détourner les utilisateurs lorsque vous souhaitez mettre à jour le primaire. Ensuite, vous renversez vos utilisateurs à la primaire après la mise à jour.

Vous pouvez utiliser le serveur d'état assis sur un autre serveur pour vous assurer que tout état de session est maintenu lorsqu'il passe de l'une à l'autre.

Nous expérimentons actuellement le cadre Web de Microsoft, qui semble très bien faire ce genre de chose.

Notre configuration implique un serveur avant, un serveur Web primaire et secondaire et un serveur d'état distinct. WFF conserve des copies d'applications Web en synchronisation sur les machines et sur le serveur d'état garantit que si un utilisateur commute des serveurs entre les demandes (ou leur serveur actuel est hors ligne), qu'ils ne devraient pas remarquer le changement.

Pour mettre à niveau le primaire, prenez-le hors de l'équilibrage de la charge qui détournera toutes ses demandes au serveur secondaire. Faites votre mise à niveau, remettez-la en rotation, puis répétez le processus avec le deuxième serveur.


0 commentaires

0
votes

Une autre option consiste à avoir deux dossiers que vous alternez entre chaque déploiement, comme dans Déploiement bleu-vert . Ainsi, lorsque le dossier bleu est actuellement en direct, vous déployez le nouveau codeBase dans le dossier vert, puis lorsqu'il est prêt, vous modifiez les paramètres IIS pour pointer vers le dossier vert.


0 commentaires