christian lapointe
Articles de christian :
GreenPepper upgrade on the way
Hi all,
We are actually aware that GreenPepper is not compatible with Confluence 4.0, .Net 4.0 and the last version of Jira, Bambo and Xwiki. The fact is that GreenPepper is no longer managed by Pyxis Canada. The product was transferred to the new subsidiary of Pyxis in Switzerland and the development was halted for several months during this process.
The good news is that the swiss team took the product back on hand a few weeks ago and are actively working on those compatibility problems. We planned a new release for November that will make GreenPepper works with Confluence 4.0, .Net 4.0 and other systems.
Support and product development are always assured and we will make every effort to answer all your questions and deliver a product tailored to your needs.
Best regards,
The swiss GP team.
Ressourcer mon Scrum Mastering
Ken Schwaber et Jeff Sutherland, les co-fondateurs de Scrum, ont publié une version révisée du Scrum Guide dernièrement. On y parle de « forecast » au lieu de « commitment », de backlog ordonné au lieu de priorisé. Mais où est donc passé le release planning?
Je ne vais pas commenter ces changements car plusieurs autres l’ont déjà fait. Mais la lecture des « update notes » m’a rappelé comment Scrum a bien évolué au cours des dernières années. Il faut dire que j’ai suivi la formation Scrum Master avec Ken Schwaber il y a déjà bien longtemps de cela, en 2003. Au fur et à mesure des projets, ma compréhension de Scrum a évolué. J’évite les choses qui n’ont pas bien fonctionné la première fois et je capitalise sur les succès. Grâce à des lectures et à des échanges avec d’autres Scrum Masters, je me suis bâti ma propre petite implémentation de Scrum basée sur ma compréhension du framework.
Lire la suite »
Agile jusqu’à la mise en production
C’est maintenant indéniable, on réussit à faire du développement itératif et incrémental dans les grandes entreprises. Plusieurs fois, cependant, c’est lors du transfert à l’équipe d’opérations pour la mise en production que la sauce se gâche, du point de vue Agile du moins.
Dans les plus petites compagnies, l’équipe de développement prend souvent en charge la mise en production. Elle est à l’aise avec sont produit, connaît les dernières modifications et sait ce qu’il y a à faire. Les équipes plus disciplinées, lire professionnelles, automatisent le tout et utilisent des architectures qui facilitent les migrations et les retours en arrière.
Dans les plus grands déploiements, pour différentes raisons comme la sécurité et le volume, il y a généralement une équipe d’exploitation qui s’occupe des mises en production.
Un scénario typique pourrait ressembler à celui-ci. L’équipe de dev fournit une boite noire aux opérateurs, parfois peu de temps avant la date de mise en production. Tout le monde se ‘parle’ par courriel et boîte vocale. Et, finalement, lorsque le déploiement ne fonctionne pas bien et après un week-end sans dormir, le jeu du blâme commence. Pour la fois suivante, on exige un document de mise en production de 30 pages et une définition détaillée de toutes les configurations, des gels de code, des tickets préautorisés avec un délai de deux semaines… Deux équipes se forment. Eux et nous, et évidemment, ce sont eux qui ont tort et qui ne connaissent rien.
Le mouvement DevOps cherche à éliminer ce problème. DevOps, c’est un ensemble de principes et surtout une entente de collaboration entre l’équipe de dev et les opérateurs. Il s’agit de rendre Agile toute la chaine de développement jusqu’à la mise en production. Après tout, un produit non déployé a un ROI de zéro. Et on a tellement travaillé fort en dev pour maximiser le ROI qu’il ne faut pas s’arrêter là.
Avec DevOps, on implique les opérateurs plus tôt. On ajoute peut-être même quelques stories afin de les aider à faire leur boulot. On les écoute, car ce sont eux qui ont le contact direct avec notre application dans les conditions réelles d’utilisation. Du coup, cela a une influence sur notre architecture.
De l’autre côté, les opérateurs s’ajustent à notre calendrier d’itérations et ont une participation plus active aux activités de préproduction afin de commencer plus tôt à comprendre et automatiser le processus.
Au final, on utilise les mêmes outils pour la documentation et le débogage et on développe un langage commun.
DevOps, c’est évidemment beaucoup plus que ces quelques petites lignes. Faites une petite recherche sur le Net. Vous allez constater que c’est un mouvement en pleine émergence. Rien de révolutionnaire ni de vraiment nouveau, mais un ensemble de bonnes pratiques qui ont du gros bon sens.
Collaboration, écoute, langage commun, outils communs, processus légers, risques identifiés plus tôt, architecture adaptée… Ça ressemble drôlement à de l’Agile non?
L’idée de ce blogue m’est venue à la suite de la présentation intitulée « DevOps: Retour d’expérience chez eXo Platform » au GenevaJUG du mois d’août. Merci à Henri Gomez pour cette présentation.
