Je suis actuellement sur un court projet de recherche. La société que je travaille a un processus de libération très lourd qui s'aggrave au fil du temps. Nous rencontrons de plus en plus de problèmes avec chaque version, qui commence à avoir gravement impact sur nos calendriers de livraison et la qualité de chaque version. Nous fournissons un grand produit SaaS déployé sur Internet sur une très grande ferme Web. Notre processus de déploiement est actuellement géré par une équipe dédiée, avec une implication minimale du développeur. Nous sommes principalement une boutique .net, mais nous avons également quelques composants Java.
Je recherche comment nous pourrions améliorer notre processus d'assurance qualité et de déploiement afin de réduire les déchets et d'apporter davantage le processus sous l'aile de nos équipes de développement. Je suis intéressé à entendre comment votre entreprise déploie vos produits (de préférence SaaS, mais sans se limiter à ces produits) de la production, ainsi que du voyage en effectuant des tests sur son chemin. Je suis curieux ce qui a fonctionné et ce qui n'a pas, et je suis sûr que beaucoup d'entre vous ont des histoires à raconter.
edit (RFC supplémentaire):
Comme j'ai poursuivi mes recherches, j'ai rencontré le concept de "déploiement continu", apparemment pionnier de l'équipe communautaire en ligne IMVU 3D. Cela ressemble à un concept intrigant, si peut-être un peu complexe. Je suis curieux si quelqu'un ici a une expérience de déploiement continu? En particulier avec un grand projet complexe qui y a de nombreuses parties. Vous n'avez pas nécessairement de déployer continuellement en production ... Pour nos besoins à court terme, nous ne chercherons que le déploiement continu aux environnements internes de Dev / QA / Perftest. Si quelqu'un a mis en œuvre un déploiement continu, je suis également curieux d'entendre la manière dont vous avez géré le schéma de base de données et les modifications de données / Rollbacks.
Merci!
4 Réponses :
Nous déployons une solution de services financiers SaaS à l'environnement Amazon AWS Cloud. Notre solution est 100% Java si de nombreux outils ne vous sont pas applicables, mais les concepts devraient.
Tout d'abord, nous réduisons le nombre de surprises lorsqu'il s'agit de faire une libération en exécutant un processus d'intégration continue. Tout type de code source est enregistré par n'importe quel développeur, la solution complète est automatiquement construite et que tous les tests d'unités sont automatiquement exécutés. Les notifications d'échec sont envoyées par courrier électronique au développeur en question et en chef de l'équipe.
AWS est construit autour du concept de machines virtuelles. Nous tirons parti de cela en créant une image de machine virtuelle (Amazon appelle les AMI) qui contiennent la version spécifique du système d'exploitation et des applications (Java, DB, etc.) que nous désirons. Le processus de construction crée tous les artefacts déployables, puis les copie à une instance de fonctionnement en fonction de cet ami. C'est exactement le même processus pour tous les environnements (test, démo, prod), à l'exception d'un seul projet de configuration qui encapsule les différences de version (par exemple les chaînes de connexion).
QA teste le résultat dans l'environnement de test. Une fois qu'ils approuvent la version, nous répétons que le processus de construction ciblant Prod (en utilisant exactement les mêmes révisions de contrôle de la version. N'oubliez pas que la seule différence entre chaque environnement est un projet de configuration).
À ce stade, nous créons une machine virtuelle (instance) en cours d'exécution sur la base AMI avec la base de code Prod et l'appelez-la. La mise en scène passe par une série de tests d'acceptation, automatisés et manuels. Voici la très belle partie ... Maintenant, nous brûlons cet environnement (base AMI et nouvelle version de notre application) dans un Nouveau AMI (Image de la machine virtuelle). Ensuite, nous créons de nouvelles instances d'exécution de nos serveurs d'applications basés sur cette nouvelle image, mettez à jour l'équilibreur de chargement pour pointer vers ces nouvelles instances et tuer les anciennes instances. C'est la beauté de l'utilisation de machines virtuelles (au moins, c'est l'une des beauté).
Chaque fois que nous devons ajuster la capacité (heures de pointe / jours), nous créons de nouvelles instances de serveur d'applications à partir de la même production AMI et enregistrez-les avec l'équilibreur de charge. Lorsque le sommet est terminé, nous venons de les retirer de la rotation de l'équilibrage de la charge, puis de tuer les instances supplémentaires après quelques minutes (permettant de compléter les sessions existantes).
Merci pour la réponse détaillée. Cela ressemble à la clé qui vous a aidé à utiliser des machines virtuelles. L'un des produits que nous évaluons est VMware Lab Manager. De ce que j'ai rassemblé à propos de AMI, il sert le même but de base ... des machines virtuelles basées sur des modèles. Je suppose que la principale différence est qu'elle serait hébergée par nous sur notre propre matériel. C'est bon d'entendre un scénario où la virtualisation a été utilisée avec succès (et dans le nuage, de démarrer!)
J'ai demandé à Jamiedp cette question aussi, mais quelle est votre application? Souhaitez-vous le classer comme petit, moyen, grand ou énorme? Ceci est en ce qui concerne la taille de la base de code, la quantité de configuration et le numéro des utilisateurs en moyenne. Merci!
@jrista: Je suppose que cela dépend de la façon dont vous définissez ces tailles, mais de grands sons à peu près bien. L'application est relativement complexe, utilise une utilisation intensive des technologies d'entreprise et prend en charge un volume de transactions assez élevé.
Taille comme une sorte de fusion de la taille de la base de code, de la quantité de configuration, du nombre d'utilisateurs / charge moyenne, etc. Une estimation approximative de la taille globale du projet. Je suppose que c'est un peu difficile de balayer, c'est pourquoi je l'ai laissé quelque peu arbitraire (petit / med / grand / énorme). Merci pour l'information, BTW. Nous sommes intrigués par votre succès avec l'hypervirtualisation, comme c'était l'une des choses essentielles que nous examinions. Nous avons décidé d'utiliser VMware Lab Manager comme composant clé de cette nouvelle initiative. Nous devons maintenant affiner le processus de construction et de déploiement réels.
Vous voudrez peut-être vérifier cette initiative qui a développé un projet de recherche UCSB. Il fournit un environnement cloud gratuit (surtout) Amazon-compatible. Nous voulons y étudier pour la gestion des environnements de développement / test mais nous n'avons pas encore eu le temps. eucalyptus.com
@Ericj., Lorsque vous dites "nous tuons l'ancienne instance", qu'en est-il des écritures (d'utilisateurs) qui se produisent au cours de cette période? Est-ce qu'ils sont effacés?
@Pacerier: Non, bonne prise. Le libellé de ma dernière phrase était imprécis. Nous supprimons d'abord des instances supplémentaires afin qu'elles ne reçoivent pas de nouvelles sessions qui leur fonctionnent, puis supprimez les instances donnant aux connexions existantes une chance de terminer. Si vous avez des sessions collantes (un utilisateur connecté reste sur la même machine), vous devrez attendre plus longtemps que si vous autorisez des sessions à traverser des machines.
Vous ne dites pas ce qui cause les problèmes avec vos versions? Nous avions des problèmes parce que les mauvais fichiers se retrouvaient dans notre construction. Notre réponse à cela était de créer un outil qui nous donnerait un contrôle et une visibilité à tous les fichiers de notre construction. ici est une diffusion Web de l'outil que nous avons construit.
N'étaient pas exactement sûrs ce qui provoque spécifiquement des problèmes. Nous savons qu'une partie de cela concerne la manière dont nos scripts de construction fonctionnent et que nos scripts de construction sont étroitement couplés à la structure de dossier spécifique et à la structure de ramification de notre contrôle source. Un autre problème que nous pensons avoir est trop de processus, ce qui nécessite un lot de personnes à participer à chaque version. Nous savons que nous devons appuyer sur le processus ... mais nous n'avons pas de "bon processus de déploiement" de base à comparer à.
La diffusion Web au lien que vous avez fourni semble être cassée. Cela commence à jouer pendant quelques secondes, puis s'arrête.
Disclaimer strong>: Je peux vendre ce que j'ai écrit, mais pour l'instant, c'est gratuit (et non officiellement libéré). Nous utilisons un système que j'ai écrit. P> Il fonctionne en intégrant avec votre commande source et votre serveur CI. Cela me permet de commettre le code à svn, attendez une construction sur le serveur de construction, puis via l'interface des applications, configurez-la pour une construction spécifique, commettez-la back em> dans le contrôle de la source, puis Sur les serveurs, il mettra à jour. La belle chose est que vous puissiez mettre à jour ASYNCH, tous les serveurs recevront la nouvelle construction à la fois. P> C'est un peu plus compliqué que cela et nécessite une certaine façon d'être mis en place, mais C'est vraiment assez beau (dans mon opinion très biaisée) quand elle est en action. Tirez-moi un email si vous souhaitez une version gratuite 'Alpha' à jouer avec. Toute version bêta sera aussi libre. P> - Edit: p> Processus général: P> Les phases "Déployer" consistent à s'engager vers SVN, puis le programme, également installé sur vos serveurs Web, obtient la construction de svn. p> efficacement, j'ajoute un nouveau " Base «Niveau d'objet dans votre structure SVN standard. Vous avez normalement: p> avec dashy, j'ajouterais
/ rejets p> p> /trunk
/braches
/tags
/releases
Donc, est-ce un système de construction préventif, qui intercepte la vérification et la construction avant que le code soit engagé (comme TeamCity?) Je ne suis pas sûr de bien comprendre ce qu'il fait ...
Merci. Ça a l'air intéressant. Je suis curieux si vous avez déjà entendu parler de TeamCity? C'est un autre produit CI que j'évalue. La chose intrigante à propos de TC est qu'elle intercepte de manière préemptive les checkins de contrôle de la source, construit et vérifie et ne marque que la vérification du contrôle de la source si la construction et la vérification réussissent. Sinon, le délinquant est notifié dans une boucle fermée et vous ne rencontrez pas le problème du mauvais code frappant une branche. Je ne sais pas quels types de scénarios de déploiement il prend en charge, mais le déploiement peut être traité par le script de construction de toute façon. jetbrains.com/teamcity
À partir d'une vue superficielle, TeamCity s'asseoirait au même endroit que Cruisecontrol dans le processus général dashy (c'est-à-dire comme serveur de construction). Dans quelques jours, j'aurai quelques liens avec Dashy dans mon profil et un contour beaucoup plus approfondi de la façon dont cela fonctionne (veuillez s'il vous plaît la version alpha pour tester :)
Une différence entre TeamCity et d'autres outils CI tels que Cruisecontrol, TFS Build, etc. est que TeamCity s'appuie avant que le code n'atteigne jamais le système de contrôle source. Cela empêche le code de l'insonorisation d'être vérifié et briser tout le monde qui se synchronise de ce point jusqu'à ce que la construction soit corrigée. Sa plus grande force et son plus grand point de vente, imo. Si vous construisez un serveur CI, c'est une fonctionnalité que je recommande vivement à examiner, car je pense que c'est la voie du futur pour la construction automatisée.
Jrista: Pas une mauvaise fonctionnalité, pour être sûr, mais aussi de côté, je ne construisant pas un serveur CI; Dashy sera heureusement assis sur TeamCity ou Cruisecontrol ou tout autre serveur 'Build'. Cela fonctionne avec eux.
Ah, je comprends maintenant. Vous mettez en train de mettre en place un service de déploiement continu qui se connecte à d'autres produits CI. Ça a l'air intéressant. Avez-vous déjà entendu parler de "déploiement continu" comme il est fait par l'équipe communautaire en ligne d'IMVU? Votre produit supporte-t-il quelque chose de similaire?
Nous avons une solution SaaS et utilisons essentiellement le même processus (serveur d'intégration continue, scripts de déploiement pour la production de test-stadification) comme Eric ci-dessus, mais nous le déploiions à notre propre infrastructure à l'aide de scripts personnalisés basés sur des pstools ( http://technet.microsoft.com/en-us/sysinternals/bb896649.aspx ) faire tout la copie sur les nœuds de la ferme.
Pour chaque déploiement, nous évaluons si sa possible pour permettre à différents nœuds a des versions différentes de l'application (c.-à-d. Aucun risque d'intégrité des données) ou nous devons apporter l'application hors ligne pendant quelques secondes pour synchroniser tous les nœuds (il s'agit-il habituellement prend environ 20 secondes pour que l'application soit de retour en ligne, car il suffit de faire face aux applications, d'un noeud maître); Mais toute la clé est d'avoir une configuration de processus de déploiement «une clé».
Par curiosité, quelle est votre application? Souhaitez-vous le classer comme petit, moyen, grand ou énorme? Merci. :)
La question de mon dernier commentaire concerne la taille de la base de code, la quantité de configuration et le numéro des utilisateurs en moyenne. Merci.
Toute la suite est d'environ 4 millions de lignes de code et est divisée en plusieurs composantes (extrémité avant, Web Services, Dal, etc.) que nous pourrions déployer indépendamment bien que nous ne le faisons pas. En ce qui concerne la configuration, toutes les modifications de configuration sont gérées / modifiées par nos scripts de déploiement ... et sont fondamentalement des modifications aux chaînes de connexion, les références de service, qui sont préparées sur le nœud principal et twicked sur chaque noeud comme pour le numéro des utilisateurs, nous Avoir environ 10 000 utilisateurs de REG, et pendant la journée, nous avons environ 300 sessions actives à une fois, nous essayons toujours de déployer à l'heure de choix faible, nous avons 10 ~ 15 sessions
Merci pour Thie Info. Je suppose que je vous classerais les gars comme moyen, en fonction des chiffres que vous avez donnés. (Nous avons une base de code de dizaines de millions de lignes de code, couvrant l'héritage, l'héritage et le nouveau, avec des milliers d'utilisateurs simultanés ... Nous tombons dans la grande / énorme arène.) Je suis un peu curieux exactement comment Vous utilisez des pstools pour déployer. Pourriez-vous clarifier cela un peu?
Bien sûr: le serveur CC génère la construction à partir de la branche Prod appropriée et exécute un script nant qui presse les applications et copie le code postal dans un lecteur réseau partagé visible à partir des nœuds Prod, exécute un script Nant de déploiement sur le nœud de production principal. En utilisant Psexec, après cela, le nœud principal copie et décompresse l'application localement à une part de réseau local sur le réseau Prod, modifie les fichiers de configuration et exécute un script nant sur chaque nœud qui copie localement, ajuste les configs et les déploies à IIS (avec ou sans apporter l'application hors ligne) J'espère que cela aide