intégration continue et pré-intégration

Question

Je poste une partie question-radoter partie dans l'espoir qu'il susciter la discussion ainsi que répondre à ma question, qui est plus une série d'exigences si je suis honnête.

À mon lieu de travail, sont très builds de main-d'œuvre. C'est parce que notre équipe est très petite et il y a des soupçons que l'automatisation va inévitablement mal tourner parce que nous n'avons pas l'expertise dans l'équipe pour le faire correctement. Je considère que c'est un argument raisonnable - mais imparfait. De mon côté, j'ai un cadre intermédiaire qui semble apprécier le concept d'automatisation et qui a utilisé avec succès de nombreuses petites fonctions d'automatisation.

Ce que je vise à faire est de lier une sorte d'environnement de construction automatisé avec notre système de libération, ce qui oblige les gestionnaires à produire divers documents. Ceci est une exigence de la certification TickIT et n'est pas à négocier. Ce que j'imagine faire est de produire un workflow (Windows) - pour lequel nous avons une infrastructure informatique configurée et qui est familière à l'ensemble de l'entreprise - qui invite les gestionnaires à la documentation qui doit être validée pour une génération et une publication. Nous ne sommes pas une société de logiciels, nous sommes une société qui vend des logiciels, donc ces fonctionnalités doivent être mises en place à la non-technique.

Donc, en résumé, notre cas d'utilisation ressemblerait à quelque chose comme:

• gestionnaire examine le suivi des tâches et autorise une version basée sur l'état actuel
• flux de travail démarre, après avoir mis en cache la révision SVN actuelle
• demandes de flux de travail du chef de projet un certain nombre de documents pdf, etc qui doivent être intégrés dans le package d'installation
• incendies de flux de travail hors du processus de construction sur la révision de SVN précédemment mis en cache sur un gestionnaire d'intégration tels que CruiseCont ROL (je suis compris dans ce tout ce que l'intégration continue fait, y compris les tests unitaires)
• packages d'installation terminés sont automatiquement installés sur différentes machines virtuelles (l'ensemble des systèmes d'exploitation pris en charge et les langues) et qui sont mis à la disposition QA
• à signe-off de QA, des packages d'installation complète sont libérés sur le Web

Naturellement, puisque rien ne fonctionne jamais correctement, la capacité de « casser » le flux de travail et procéder manuellement à tout moment devrait être inclus, comme nous Je ne veux pas que la libération soit retardée par une machine stupide qui ne peut pas faire son travail alors qu'un peu de bon sens ferait aussi bien.

Est-ce que quelqu'un a quelque chose qui pourrait être considéré comme une étude de cas sur ce genre de processus, ou des commentaires sur la façon simple ou difficile, il pourrait être, ou même comment il est approprié?

Answer 1

Nous avons résolu ce problème récemment pour l'un de nos clients. Notre implémentation implique les composants suivants (mais vous pouvez réaliser la même chose avec différents outils en fonction de votre organisation).

• flux JIRA - orchestrer les processus (et des mesures de performance de capture) gérer les approbations et l'histoire suivre pour la vérification
• plug-in JIRA - Trigger construit \ déploiements \ les tests via le serveur CI (Hudson \ Jenkins).Listener: répondre aux mises à jour d'état de Hudson \ Jenkins
• plug-in Jenkins - pour interagir avec JIRA
• build-pipeline-plugin - pour gérer le flux de travail Jenkins
• scripts de déploiement - orchestrée par Jenkins \ Groovy

Il semble complexe , mais beaucoup de ces outils ont d'excellentes API avec lesquelles travailler, de sorte que vous pouvez obtenir une solution stable dans un délai raisonnable.

Cheers,

Geoff

Answer 2

Après avoir fait des recherches sur ce sujet, je l'ai passé les derniers jours à jouer avec CruiseControl.NET. On dirait qu'il peut probablement faire tout ce que je cherche, en raison de son extensibilité. Il n'y a pas d'obstacle à déclencher un autre plugin à la fin de la construction qui fait tout le déploiement et la signature. Certaines des exigences sont compliquées et prennent un temps indéterminé, donc je pense qu'une sorte de persistance d'état comme WWF serait précieuse. Je vais devoir expérimenter et en parler avec mes collègues.

Answer 3

Tenir compte CloudMunch pour cela. CloudMunch fournit un moteur de construction (basé sur Jenkins), Construire flux de travail de progression au-dessus de celui-ci d'avoir flux de travail manuel géré au-dessus de celui-ci avec un support RBAC propre pour gérer ce que vous regardez.

Disclaimer: Je travaille à CloudMunch.