Est-il acceptable de déployer une application Web en production directement depuis SVN

Question

Y a-t-il une raison légitime de NE PAS utiliser SVN pour les déploiements de production, ou s'agit-il simplement d'un cas de préférence personnelle et il n'y a pas de véritable cas contre SVN?

Contexte

Mon lieu de travail a une culture de balisage des versions dans SVN, puis de déploiement de ces versions directement sur les différents serveurs Web en utilisant svn coou en svn switchincluant directement en production.

J'ai personnellement un problème avec cela car je crois que sans utiliser un script de construction et de déploiement ou un formulaire ou un déploiement automatisé, vous perdez les paramètres de l'environnement d'intégration car ils ne sont pas documentés. Cependant, plus que cela, j'ai le sentiment profond qu'il peut y avoir un danger caché à faire ce qui a été négligé, quelque chose qui n'a pas encore éveillé sa tête laide.

J'ai soulevé mes préoccupations avec le personnel des opérations qui est responsable du déploiement du code dans nos différents environnements (staging, pré-production, production) etc. Leurs arguments étaient à peu près que cela fonctionnait assez bien jusqu'à présent, aucune raison de changer.

Éditer:

Ce que je veux dire sur la construction et le déploiement:

Par exemple, si un développeur requiert un paramètre web.config ajouté pour un environnement particulier. Web.config n'est généralement pas conservé dans svn et ces fichiers sont donc mis à jour manuellement sans aucune forme de script de construction automatisé. Donc, s'ils sont perdus ou que OPS oublie d'ajouter un champ au web.config pour une version, vous avez des problèmes.

Un script de construction qui dit utilise XMLPoke pour générer automatiquement un web.config approprié pour un environnement particulier est idéal en ce que vous disposez d'un script versionnable qui documente toutes les modifications nécessaires pour chacun de vos environnements.

Méthode actuelle de génération et de déploiement

Pour le projet en question, un développeur crée une version manuellement, pour d'autres projets, l'étape de génération est automatisée avec NANT ou MSBuild, ce qui est OK.

Les migrations de base de données pour la plupart des projets se font via des scripts DB ou des scripts de migration (Migrator.NET) ou des packages CMS.

Le CI est généralement effectué par Team City sur une base par enregistrement, nous avons un processus de révision du code que tous les tickets sont effectués dans les succursales et ensuite examinés par les pairs pour la validation et l'exactitude / qualité avant de vérifier dans le coffre (fonctionne bien).

Cependant, le déploiement de code réel se fait presque toujours via SVN, soit via une extraction d'une version balisée, soit plus généralement un commutateur SVN. C'est quelque chose qui me semble étrange que nous utilisons notre référentiel dans le cadre du processus de déploiement.

La configuration ne change généralement pas très souvent, les seules choses qui seront dans les fichiers de configuration sont des informations spécifiques à l'environnement. Tout le reste est dans la base de données.

Ne vous méprenez pas, cela fonctionne, cela fonctionne bien. Cependant, je veux essayer de pousser pour une construction et un déploiement automatisés. Je l'ai utilisé avec Rails et Capistrano, et pour des projets personnels utilisant Cygwin, Nant et SSH.

Plus important encore, j'aurais besoin d'arguments valides très spécifiques pour amener mes collègues à utiliser une génération et un déploiement automatisés.

Ou n'y a-t-il PAS de véritables arguments valables contre l'utilisation de SVN spécifiquement pour le déploiement en production?

D'après mon expérience, il y a à la fois des avantages et des inconvénients:

Avantages:

• Parfois, vous effectuez des correctifs urgents sur le serveur de production, puis vous pouvez les archiver directement à partir de là. (Bien que théoriquement, pour des raisons de sécurité, il est toujours judicieux d'utiliser un accès en lecture seule au référentiel depuis le serveur de production.)

• Simplicité: vous livrez rapidement, bien que, comme d'autres l'ont mentionné ici, le passage à un schéma de script de mise à jour puisse être aussi simple.

Les inconvénients:

• Votre système peut devenir instable pendant vos svn upmises à jour et DB. Pour un site à fort trafic, cela signifie que certains utilisateurs afficheront au mieux des messages d'erreur, des pages cassées ou des pages vides. Eh bien, c'est ce que nous voyons très souvent sur divers services sociaux. Un bon service, cependant, le fait "atomiquement" dans le sens où il met le système en mode maintenance pendant la durée d'une mise à jour. ( Vous avez cassé reddit! )

• Conflits: résoudre des conflits soudains sur le serveur de production est une idée terrible: encore une fois, le service devient instable pendant que vous le corrigez.

• Fichiers non liés sur le serveur de production qui peuvent ou non vous appartenir, bien que vous puissiez bien sûr l'éviter en vérifiant le bon sous-arbre dans le référentiel.

• Sécurité: quelqu'un qui a eu accès à votre serveur de production, légitimement ou non, a également accès à vos repos, éventuellement à d'autres produits également, et éventuellement à un accès en écriture! L'ouverture globale de votre serveur SVN interne au monde extérieur est une mauvaise idée. Vos référentiels sources doivent être derrière un pare-feu d'entreprise, point final.

• Il y aura de toute façon des scripts de mise à jour, par exemple pour mettre à jour la structure de la base de données, gérer les cronjobs, etc., alors pourquoi ne pas avoir un script qui fait tout? - c.-à-d. tire la dernière version préemballée, passe en mode maintenance, met à jour les sources, exécute des scripts spécifiques à la version, etc.

Edit: pour ceux qui sont toujours sur le schéma SVN, n'oubliez pas ceci dans votre configuration apache:

<DirectoryMatch .svn>
    Order deny,allow
    Deny from all
</DirectoryMatch>

J'ai mis en place un serveur CI à mon travail qui crée automatiquement notre installateur en supposant que les tests unitaires réussissent. Cela m'a pris environ une journée de travail et cela m'a sauvé bien plus que cela depuis que je l'ai installé.

S'il y a un processus manuel dans la configuration de votre site Web de version / d'installation / de production, vous économiserez invariablement vous-même et le temps de l'entreprise. Cela vous convient car, d'après votre question, il semble qu'il y ait des étapes de configuration manuelle dans votre processus de configuration.

Pour une référence, voir Joel lui - même parler de la façon dont un processus de construction en un seul clic vous sauve à court ou moyen terme.

Assurez-vous que vous disposez des contrôles d’enregistrement appropriés sur SVN. Par exemple, considérez ceci -

• Les fonctionnalités sont archivées pour une version
• Le code est déployé dans la mise en scène, l'AQ fait son travail
• Les bugs sont corrigés, une autre série de tests (mais cela fonctionne dans votre équipe)
• Idem pour la pré-prod
• Déployer en production

Si quelqu'un effectue accidentellement des enregistrements après la phase de pré-production, il y a un risque de casser quelque chose. Si cela est contrôlé - comme dans aucun enregistrement autorisé pendant la pré-production, sauf pour les corrections de bugs - je ne vois aucun risque.

Mise à jour: vous avez un problème en attente de se produire si vous ne consignez pas vos fichiers de configuration. Je ne peux pas vraiment offrir de conseils pour cela autre que "s'il vous plaît, faites vite!"

Cela semble correct tant qu'il n'y a rien en dehors du référentiel. En fait, je crois qu'il ne faut pas investir de temps dans les outils de déploiement les premiers mois du projet. Parce qu'il y aura trop de déploiements, pas assez de clients pour se soucier d'un processus de publication officiel.

Mais une fois que le projet a environ un an, il vaut la peine d'investir dans un outil de déploiement. Des raisons simples sont

• Les affaires se développent donc vous prévoyez de l'héberger sur plusieurs serveurs
• Il peut y avoir des bogues dans un environnement particulier et vous n'avez aucun endroit pour répliquer le bogue. Il n'y a aucun moyen facile de le configurer sans un processus tar-untar-oublie_about_home_for_a_week.
• Quelqu'un est susceptible de casser la construction. Qui a cassé la construction

Si vous voulez les convaincre, demandez-leur de configurer un autre serveur pour les tests internes ou le contrôle qualité.