Quelle est la meilleure solution pour gérer le développement multiplateforme (dev/integ/valid/prod...) ? Processus de livraison

Question

Je n'ai pas beaucoup d'expérience mais j'ai travaillé sur de gros projets Java EE (utilisant maven2) avec des manières très distinctes de gérer l'installation / la livraison sur les différentes plateformes.

1) L'un d'entre eux était d'utiliser des snapshots pour le développement et ensuite de faire une version maven, des composants et des applications web principales. Ainsi la livraison est :

• dossiers de guerre/ear
• Élément de liste
• fichiers de propriétés
• Fichiers sgdb
• quelques autres

Et les équipes utiliseront ces fichiers pour mettre les nouvelles versions des applications dans les différentes plateformes. Je pense que ce processus est strict et permet de toujours garder facilement les différentes configurations passées en production, mais il n'est pas vraiment flexible, le processus est un peu lourd et il nous a conduit à faire parfois des choses sales comme remplacer une classe d'une guerre pour corriger une régression... Il s'agit d'un site de commerce électronique avec 10 millions de visiteurs uniques par mois et une disponibilité de 99,89%.

2) Une autre solution que j'ai vue consiste à extraire les sources de chaque plate-forme et à installer les artefacts instantanés dans un référentiel local. Ensuite, le serveur d'application utilisera ces instantanés du dossier .m2. Il n'y a pas de véritable processus de livraison puisque pour mettre une nouvelle version en production, il suffit de mettre à jour les sources des composants / webapps, de faire un maven clean install et de redémarrer le serveur d'application. Je pense que c'est plus flexible mais je vois quelques inconvénients et cette approche me semble dangereuse. Ce site a un frontoffice, je ne connais pas les chiffres mais c'est beaucoup moins que le premier. Il a également un grand backoffice disponible pour la plupart des employés d'une entreprise de 130 000 personnes.

Je suppose qu'en fonction du site web, de son exposition au public et de la disponibilité requise, nous devons adapter la stratégie de diffusion aux besoins.

Je ne suis pas ici pour demander quelle est la meilleure solution, mais je me demande si vous avez vu des choses différentes, et quelle stratégie vous utiliseriez dans tel ou tel cas ?

Answer 1

Sans m'occuper des sites web, j'ai dû participer au processus de gestion des versions pour divers grands projets (Java) dans un environnement hétérogène :

• développement sur "PC", c'est-à-dire dans notre cas Windows -- malheureusement toujours Windows Xp pour le moment -- (et tests unitaires)
• l'intégration continue et les tests système sur linux (parce qu'ils sont moins chers à mettre en place)
• la pré-production et la production sur Solaris (Sun Fire par exemple)

La méthode commune que j'ai vue était :

• dépendance binaire (chaque projet utilise les binaires produits par l'autre projet, et non leurs sources)
• pas de recompilation pour les tests d'intégration (les jars produits sur PC sont directement utilisés sur les fermes linux)
• recompilation complète sur la pré-production (c'est-à-dire le binaire stocké sur le repo Maven), au moins pour s'assurer que tout est recompilé avec le même JDK et les mêmes options de vente.
• pas de VCS (système de contrôle de version, comme SVN, Perforce, Git, Mercurial, ...) sur un système de production : tout est déployé de la pré-prod à la rsynch.

---

Les différents paramètres à prendre en compte pour un processus de gestion des versions sont donc les suivants :

• lorsque vous développez votre projet, dépendez-vous directement des sources ou des binaires des autres projets ?
• où stockez-vous vos valeurs de réglage ?
  Les paramétrez-vous et, si oui, quand remplacez-vous les variables par leurs valeurs finales (seulement au démarrage, ou aussi pendant l'exécution ?) ?
• recompilez-vous tout sur le système final (de pré-production) ?
• Comment accédez-vous/copiez/déployez sur votre système de production ?
• Comment arrêter/redémarrer/régler vos applications ?

(et il ne s'agit pas d'une liste exhaustive.
Selon la nature de la libération de l'application, d'autres préoccupations devront être abordées)

Answer 2

La réponse à cette question varie grandement en fonction des exigences exactes et des structures de l'équipe.

J'ai mis en place des processus pour quelques très grands sites web ayant des exigences de disponibilité similaires et je trouve que certains principes généraux ont fonctionné :

• Externaliser toute configuration de sorte que le même artefact construit puisse fonctionner sur tous vos environnements. Ensuite, ne construisez les artefacts qu'une seule fois pour chaque version - Reconstruire pour différents environnements prend du temps et est risqué, par exemple si ce n'est pas la même application que celle que vous avez testée.
• Centralisez l'endroit où les artefacts sont construits. - Par exemple, toutes les guerres destinées à la production doivent être empaquetées sur le serveur CI (l'utilisation du plugin maven release sur hudson fonctionne bien pour nous).
• Tous les modifications apportées à la version doivent être traçables (contrôle de version, tableau d'audit, etc.), pour garantir la stabilité et permettre des retours en arrière et des diagnostics rapides. Cela ne doit pas nécessairement signifier un processus lourd - voir le point suivant.
• Automatisez tout, la construction, les tests, la diffusion et les retours en arrière. Si le processus est fiable, automatisable et rapide, le même processus peut être utilisé pour tout, des corrections rapides aux changements urgents. Nous utilisons le même processus pour une correction d'urgence de 5 minutes et pour une version majeure, car il est automatisé et rapide.

Quelques indications supplémentaires :

Voir ma réponse Emplacement de la propriété d'une autre propriété pour un moyen simple de charger différentes propriétés par environnement avec spring.

http://wiki.hudson-ci.org/display/HUDSON/M2+Libération+Plugin Si vous utilisez ce plugin et que vous vous assurez que seul le serveur CI dispose des informations d'identification correctes pour effectuer les releases maven, vous pouvez garantir que toutes les releases sont effectuées de manière cohérente.

http://decodify.blogspot.com/2010/10/how-to-build-one-click-deployment-job.html Un moyen simple de déployer vos versions. Bien que pour les sites de grande taille, vous aurez probablement besoin de quelque chose de plus compliqué pour garantir l'absence de temps d'arrêt - par exemple, déployer sur la moitié du cluster à la fois et basculer le trafic web entre les deux moitiés. http://martinfowler.com/bliki/BlueGreenDeployment.html

http://continuousdelivery.com/ Un bon site web et un bon livre avec de très bons modèles pour la libération.

J'espère que cela vous aidera - bonne chance.

Answer 3

Pour compléter ma réponse précédente, ce à quoi vous avez affaire est essentiellement un problème de CM-RM :

• CM (gestion du changement)
• RM (gestion des versions)

En d'autres termes, après la première version (c'est-à-dire lorsque le développement initial principal est terminé), vous devez continuer à produire des versions, et c'est ce que CM-RM est censé gérer.

La mise en œuvre de la RM peut être soit 1) soit 2) dans votre question, mais mon propos serait d'ajouter à ce mécanisme :

• une gestion des connaissances appropriée afin de suivre toutes les demandes de changement et d'évaluer leur impact avant de s'engager dans un développement.
• une bonne gestion des ressources humaines afin de pouvoir réaliser les tests de "libération" (tests de système, de performance, de régression, de déploiement), puis de planifier, de programmer, d'exécuter et de surveiller la libération elle-même.

Answer 4

Sans prétendre que c'est un meilleur C'est ainsi que mon équipe procède actuellement à la mise en place et au déploiement de la solution.

• Les développeurs développent initialement sur leur machine locale, le système d'exploitation est libre de choisir, mais nous encourageons fortement l'utilisation de la même JVM que celle qui sera utilisée en production.
• Nous avons un DEV où des instantanés fréquents du code sont poussés. Il s'agit simplement d'un scp à partir de la construction binaire produite par l'IDE. Nous prévoyons cependant de construire directement sur le serveur.
• Le site DEV est utilisé pour que les parties prenantes puissent suivre le développement en permanence. De par sa nature même, il est instable. Ceci est bien connu de tous les utilisateurs de ce serveur.
• Si le code est suffisamment bon, il est branché et poussé vers une BETA serveur. Là encore, il s'agit d'un scp d'une construction binaire à partir de l'IDE.
• Les tests et l'assurance qualité générale ont lieu sur ce site. BETA serveur.
• Pendant ce temps, si des changements urgents devaient être nécessaires pour le logiciel actuellement en production, nous avons un troisième serveur de transit appelé le UPDATE serveur.
• Le site UPDATE n'est initialement utilisé que pour réaliser de très petites corrections. Ici aussi, nous utilisons scp pour copier les binaires.
• Après avoir effectué tous les tests sur UPDATE nous copions la construction à partir de UPDATE a LIVE . Rien ne va jamais directement sur les serveurs live, mais toujours via le serveur de mise à jour.
• Lorsque tous les tests seront terminés sur BETA la version testée est copiée du serveur bêta vers le serveur de l'entreprise. UPDATE et une dernière série de tests d'intégrité est effectuée. Comme il s'agit de la version exacte qui a été testée sur le serveur bêta, il est très peu probable que des problèmes soient découverts à ce stade, mais nous maintenons la règle selon laquelle tout ce qui est déployé sur le serveur live doit passer par le serveur de mise à jour et que tout ce qui se trouve sur le serveur de mise à jour doit être testé avant d'être déplacé.

Cette stratégie de glissement nous permet de développer pour 3 versions en parallèle. La version N qui est actuellement en production et mise à disposition via le serveur de mise à jour, la version N+1 qui sera la prochaine version majeure sur le point d'être publiée et qui est mise à disposition sur le serveur bêta, et la version N+2 qui est la prochaine version majeure pour laquelle le développement est actuellement en cours et qui est mise à disposition sur le serveur de développement.

Certains des choix que nous avons faits :

• Une application complète (un EAR) dépend généralement d'artefacts provenant d'autres projets. Nous choisissons d'inclure les binaires de ces autres projets au lieu de construire l'ensemble à partir des sources. Cela simplifie la construction et donne une plus grande assurance qu'une application testée est groupée avec exactement les bonnes versions de toutes ses dépendances. Le coût est qu'une correction dans une telle dépendance doit être distribuée manuellement à toutes les applications qui en dépendent.
• La configuration de chaque étape est intégrée dans l'EAR. Nous utilisons actuellement une convention de nommage et un script copie la bonne version de chaque fichier de configuration au bon endroit. Il est actuellement envisagé de paramétrer le chemin de chaque fichier de configuration, par exemple en utilisant un seul {stage} dans un fichier de configuration Root. La raison pour laquelle nous stockons la configuration dans l'EAR, est que les développeurs sont ceux qui introduisent et dépendent de la configuration, donc ils devraient être les responsables de sa maintenance (ajout de nouvelles entrées, suppression des entrées inutilisées, modification des entrées existantes, etc).
• Nous utilisons un DevOps stratégie pour une équipe de déploiement. Elle se compose d'une personne qui est purement développeur, de deux personnes qui sont à la fois développeur et opérations et de deux personnes qui sont purement opérations.

L'intégration de la configuration dans l'EAR pourrait être controversée, car traditionnellement, les opérations ont besoin de contrôler, par exemple, les sources de données de la base de données utilisées en production (vers quel serveur elles pointent, combien de connexions un pool de connexion est autorisé à avoir, etc). ). Cependant, comme certains membres de l'équipe de développement font également partie de l'équipe d'exploitation, ils peuvent facilement vérifier les modifications apportées par d'autres développeurs à la configuration alors que le code est encore en cours de développement.

Parallèlement au staging, le serveur de construction continue effectue une construction scriptée (ANT) après chaque check-in (avec un maximum d'une fois toutes les 5 minutes), et exécute des tests unitaires et quelques autres tests d'intégrité.

Il reste difficile de dire s'il s'agit d'une le meilleur des deux mondes et nous essayons constamment d'améliorer notre processus.

Answer 5

Je suis un grand partisan d'un un seul déployable contenant tout (Code, Config, DB Delta, ...) pour tous les environnements construit et diffusé de manière centralisée sur le serveur CI.

L'idée principale derrière cela est que Le code, la configuration et la base de données Delta sont étroitement liés. de toute façon. Le code dépend de certaines propriétés définies dans la configuration et de la présence de certains objets (tables, vues, ...) dans la base de données. Alors pourquoi diviser ce code et passer votre temps à tout suivre pour vous assurer que tout s'emboîte, alors que vous pouvez simplement l'expédier ensemble dès le départ.

Un autre aspect important est minimiser les différences entre les environnements afin de réduire les causes de défaillance au strict minimum.

Plus de détails dans mon Livraison continue parler sur Parleys : http://parleys.com/#id=2443&st=5