Comment améliorer notre processus de construction et de déploiement?

Question

Notre processus de génération/déploiement est très fastidieux, suffisamment manuel et sujet aux erreurs. Pourriez-vous faire des propositions d'amélioration? Permettez-moi de décrire notre stratégie de déploiement et notre processus de construction. Nous développons un système appelé Application Server (AS pour faire court). Il s'agit essentiellement d'une application Web basée sur les servlets hébergée sur le serveur Web JBoss. AS peut être installé dans deux "environnements". Chaque environnement est un répertoire avec le code de la webapp. Ce répertoire est placé sur le stockage réseau. Le stockage est monté sur plusieurs serveurs de production où les instances JBoss sont installées. Le répertoire est lié au répertoire webapps de JBoss. Ainsi, toutes les instances de JBoss utilisent le même code pour l'environnement. La configuration de JBoss est séparée de l'environnement et mise à jour par instance.

Nous avons donc deux types de patchs: patches de webapp (pour différents environnements) et les correctifs de configuration (pour par exemple la configuration)

Patch est un fichier exécutable. En fait, c'est un script bash avec un paquet rpm binaire intégré. L'installation est assez simple: vous n'avez qu'à exécuter le fichier et éventuellement répondre à quelques questions. Le point important est que le correctif n'est pas un système dans son ensemble - il contient seulement quelques classes avec des correctifs et/ou des scripts qui modifient les fichiers de configuration. Les classes sont copiées dans WEB-INF/classes (AS est déployé en tant que répertoire éclaté).

La façon dont nous construisons ces chemins est:

1. Nous prenons des fichiers correctifs précédents et de les copier.
2. Nous modifions le contenu du patch. La partie la plus importante est RPM spec. Là, nous changeons le nom du patch, changeons ses paquets rpm prérequis et notons les commandes bash pour sauvegarder, copier et modifier les fichiers. C'est l'une des parties les plus agaçantes parce que nous ne pouvons pas toujours obtenir des changements réels. Cela est particulièrement vrai pour les nouvelles fonctionnalités complexes qui sont réparties entre plusieurs demandes de modification et validations. En outre, écrire ces commandes pour change-set est fastidieux et sujet aux erreurs.
3. Pour les correctifs webapp, nous modifions également les spécifications pour les autres environnements. Habituellement, ils sont identiques à l'exception du nom du paquetage rpm.
4. Nous avons mis tous les fichiers liés rpm à VCS
5. Nous modifions build.xml en ajoutant quelques cibles pour construire un nouveau patch. La modification est effectuée par copyptage et édition.
6. Nous modifions la configuration de CruiseControl par copypasting projet et la modification des objectifs de fourmis dans ce
7. Enfin, nous construisons un système

Aussi, je suis intéressé par toutes les références sur les pratiques de préparation et de déploiement patch, de préférence pour Applications Java. Je n'ai pas réussi à googler ça.

Answer 1

L'endroit où je travaille avait des problèmes similaires, mais peut-être pas aussi complexe.

Nous avons répondu en éliminant complètement le concept de patch. Nous avons arrêté de patcher, et avons simplement commencé à installer l'application entière (même si nous faisons juste un petit changement).

Nous avons maintenant des kits d'installation complets Cruise Control qui contiennent l'horodatage de construction dans le nom du kit d'installation. Ceci est un artefact de construction Cruise Control. Le régulateur de vitesse les intercepte automatiquement sur un serveur de test et exécute des tests de fumée automatisés. Nous effectuons ensuite des tests manuels sur le serveur de test.Ensuite, nous installons l'artefact sur une scène, puis sur le serveur de production. Se débarrasser des correctifs a fait que certaines personnes ont craché «n'est-ce pas un gaspillage si vous changez juste quelques choses? et "pourquoi écraserais-tu tout le logiciel juste pour patcher quelque chose?" Mais en vérité, un bon contrôle de la source, la construction automatisée du kit d'installation et l'installation en une seule étape nous ont fait gagner énormément de temps. Cela prend quelques secondes de plus à installer, mais nous pouvons le faire beaucoup plus à plusieurs reprises et avec moins de travail de développeur.

Answer 2

Nous essayons également d'évoluer vers des versions correctif/correctif, ainsi que de libérer des packages d'installation complète basés sur RPM. Je dois dire que je suis également d'accord que, dans la plupart des cas, cet effort est un gaspillage et j'irais aussi pour libérer le paquet d'installation complet en supposant que vous avez déjà un pipeline de build établi.

Dans notre cas, nous avons une livraison multi-modules, chacun emballé comme un RPM et enveloppé dans un ISO pour la livraison. Nous visons à garder notre pipe-line de construction pour la plupart inchangée pour libérer des correctifs. Par conséquent, nous nous concentrons à la place pour rendre nos RPM plus précis (RPM plus petits et plus ciblés) afin que nous puissions seulement libérer les RPM qui contiennent des artefacts modifiés pour un correctif/patch donné. De cette manière, les RPM de version complète et les RPM de correctifs sont les mêmes, la seule différence est le nombre de RPM que vous empaquetez dans votre ISO de livraison.

J'ai une autre question portant sur cette question, vous pouvez jeter un oeil à là:

hotfix-patch-build-delivery-approach