TFS 2015: Customisation des activités de build (part2)

Auteur original, de notre ancien blog : Laurent Jacques

tfs1

Aujourd’hui nous allons discuter de la customisation des activités de build avec TFS 2015.En effet, alors que dans un prochain billet j’aborderai le tout nouveau système de build vNext ; il me semblait important de souligner une des (nombreuses) possibilités de customisation du mécanisme existant.

Etant donné le nombre d’étapes, j’ai scindé cette présentation en 2 parties : 

  1. la création d’un nouvelle activité (voir TFS 2015: Customisation des activités de build (part1))
  2. l’intégration du workflow dans la définition de la build.
 

PART2 : Intégration du workflow dans la définition de build.

Lire la suite

TFS 2015: Customisation des activités de build (part1)

Auteur original, de notre ancien blog : Laurent Jacques

tfs9

Aujourd’hui nous allons discuter de la customisation des activités de build avec TFS 2015. En effet, alors que dans un prochain billet j’aborderai le tout nouveau système de build vNext ; il me semblait important de souligner une des (nombreuses) possibilités de customisation du mécanisme existant. Etant donné le volume d’étapes je présenterai la customatisation en 2 parties : 

  1. la création d’un nouvelle activité de build,
  2. l’intégration du workflow dans la définition de build.
PART1 : Création d’une nouvelle activité de build.

Lire la suite

« Livrer chaque jour ce qui est prêt ! » – Le Continuous Delivery chez LesFurets.com, par Dimitri Baeli

Sous l’impulsion de Rui Carvalho, Yannick Grenzinger et Soft’it, le groupe « Continuous Delivery Paris » se relance et a été finalement renommé en « Continuous Delivery to Lean Enterprise – Paris ».

Pour notre premier event public, nous avons la chance d’accueillir un grand nom de la communauté Agile & DevOps : Dimitri Baeli.
Ce dernier est R&D Team Mentor chez LesFurets.com, et aussi organisateur de Lean Kanban France.


Dimitri Baeli va donc faire une conférence/retour d’expérience sur le Continuous Delivery mis en place chez LesFurets.com.
Un site grand public a toujours de fortes contraintes de disponibilité ; il est donc indispensable de pouvoir le faire évoluer continuellement sans impacter le trafic et les utilisateurs, au risque de les perdre.

Le Continuous Delivery est le thème DevOps du moment. Facebook, Etsy, Amazon, et cie. sont en mesure de déployer plusieurs milliers de fois par jour en production et de manière transparente…pourquoi pas nous !
Vous verrez donc différentes techniques, outils et process permettant de garantir à tout moment que chaque développement n’amène pas de régression et peut être délivré en production.

CLT/Soft’it hoste l’événement dans ses propres locaux ; un réagencement de ces derniers a donc été réalisé pour l’occasion. Plus d’une cinquantaine de participants sont attendus. La soirée promet d’être enrichissante !

Nous ne manquerons pas de vous faire suivre cet événement, et de vous donner notre feedback par la suite.

Si vous désirez plus d’informations et/ou vous inscrire au Meetup, c’est ici : http://www.meetup.com/Paris-Continuous-Delivery-to-Lean-Enterprise/events/220046012/

Twitter

http://platform.twitter.com/widgets/follow_button.a5bbbb7216610af1306d56b0f28a67d7.fr.html#_=1424729059607&dnt=false&id=twitter-widget-0&lang=fr&screen_name=softitclt&show_count=false&show_screen_name=true&size=l
window.twttr=(function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],t=window.twttr||{};if(d.getElementById(id))return;js=d.createElement(s);js.id=id;js.src= »https://platform.twitter.com/widgets.js »;fjs.parentNode.insertBefore(js,fjs);t._e=[];t.ready=function(f){t._e.push(f);};return t;}(document, »script », »twitter-wjs »));

http://platform.twitter.com/widgets/follow_button.a5bbbb7216610af1306d56b0f28a67d7.fr.html#_=1424729059609&dnt=false&id=twitter-widget-1&lang=fr&screen_name=dbaeli&show_count=false&show_screen_name=true&size=l
window.twttr=(function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],t=window.twttr||{};if(d.getElementById(id))return;js=d.createElement(s);js.id=id;js.src= »https://platform.twitter.com/widgets.js »;fjs.parentNode.insertBefore(js,fjs);t._e=[];t.ready=function(f){t._e.push(f);};return t;}(document, »script », »twitter-wjs »));

Introduction à la gestion des cycles de vie des applications (ALM)

Introduction à la gestion des cycles de vie des applications

(Application Lifecycle Management – ALM)

       ….

Evidemment, dit comme cela, cela peut paraître un peu abrupte voire déconcertant … Cycles de vie des applications  – Application Lifecycle Management. Mais sous ce nom se cache en réalité l’une des meilleures pratiques logicielles dont l’objectif est de fournir un logiciel de haute valeur et de haute qualité, et ce d’une manière très efficace, rapide et fiable

Quelles sont les différentes étapes de l’ALM ? 

D’un point de vue du développeur, il est courant de penser que le cycle de vie d’un logiciel commence et s’arrête lors du checkout et du commit des modifications du code. 

La réalité est tout autre, comme nous le voyons tous les jours, et couvre beaucoup plus. 

Le cycle de vie des applications commence à partir de la création du projet jusqu’à la livraison en production, comprenant plusieurs étapes dont le développement n’est qu’une petite partie parmi, entre autres, les tests, les documentations et la génération d’installateurs. 

L’ensemble de ces opérations permet de livrer un logiciel de haute valeur et de haute qualité pour le client.

Ce schéma montre le pipeline de déploiement idéal. On y retrouve l’ensemble des opérations automatisées à mettre en place lorsqu’on parle d’ALM.
Le processus est entièrement automatisé, capable de fournir un feedback détaillé de son statut et de celui de ses opérations, et de s’interrompre à chaque étape en cas de détection d’anomalies.
Bien loin de ce déroulement idéal, le plus souvent, il est fréquent que la plupart de ces opérations soient manuelles, partielles et sans fournir de réel feedback.
Même si maintenant il est largement admis que le code source doit être hébergé dans un outil de contrôle de version, et que chaque développeur doit faire des check-out et commit réguliers, il est encore très rare de trouver une plateforme d’intégration continue réelle automatisée, qui gère ne serait-ce que la compilation automatique et le déroulement des tests unitaires. 
A la place, il est fréquent qu’il y ait des flux allant dans toutes les directions, sources de risques et de problèmes à venir, comme le montre le schéma ci-dessous  : 

Quel est le problème avec la livraison de logiciels ? 


  1. Les opérations sont nombreuses, souvent manuelles et sur différents environnements techniques mal maitrisés,
    • Le corollaire est que ces opérations dépendent de quelqu’un (responsable déploiement, chef de projet, expert quelconque). La question est donc : que se passe t’il lorsque cette personne est absente
    • extrêmement répétitives, ces tâches sont une plaie sur le long terme,
    • la réalisation d’une documentation souvent lourde est nécessaire,
    • une courbe d’apprentissage lente pour l’ajout de nouveaux membres à l’équipe,
    • des besoins humains supplémentaires sont nécessaires à l’équipe

  2. Le code source et les paramétrages ne sont pas nécessairement stockés dans le même endroit, mais peuvent être générés à partir de partout et par n’importe qui, n’importe quand : qui contrôle quoi ?
  3. Aucune vraie traçabilité,
  4. Des délais de livraison très long : il peut se passer des jours entre la validation et le déploiement,
  5. Des erreurs sont plus enclines à apparaître. 
En bref : lorsqu’il y a des opérations manuelles, il devient vraiment difficile de répéter, de cadencer et de mesurer la livraison. 

Quels sont les objectifs de l’ALM ? 

Comme vous l’aurez compris maintenant : implémenter l’ALM c’est principalement se concentrer sur l’automatisation de la grande majorité (sinon la totalité) des opérations ; afin d’assurer la création de valeur et des livraisons fiables, rapides et cadencées.
L’idée maîtresse est de réduire les temps de cycle.
Plus le temps de cycle est court, plus le client pourra être satisfait (par plus de fonctionnalités ou même par des corrections de bugs). L’objectif est de favoriser les feedbacks rapides.

Comment? 

Etant donné que cet article est seulement une (très) courte introduction, nous ne plongerons pas plus à fond dans les détails ici. 
Nous énumérerons simplement les différents sujets à couvrir. Ceux-ci seront expliqués plus en détails dans de prochains articles :
  1. Configuration et installation d’un outil d’intégration continue (TFS, Hudson, CruiseControl), 
  2. Mettre au cœur de l’outil l’analyse de qualité (règles de gestion, Sonar, FxCop) ainsi que les tests, le tout avec de l’automatisation, 
  3. Mettre sous contrôle de source tous les paramètres ou fichiers de configuration pour tous les hôtes cibles, 
  4. Lister toutes les autres opérations manuelles, les automatiser et les chaîner entre elles,
  5. Modifier le processus de développement pour s’appuyer davantage sur les tests d’acceptation,
  6. Réduire les délais de feedback (testeurs, clients ….). 

Conclusion 

Cet article n’est que le premier d’une série d’articles introduisant les principes de ALM (intégration continue, déploiement continu…etc). Il vise à présenter simplement ce qui est en jeu tout en abordant les grands principes du cycle de vie des applications.
Dans les prochains articles, nous expliquerons plus en détail avec de cas concrets d’utilisation et d’implémentation, les scénarios de mise en place de l’ALM.

Liens utiles

ALM (sur wikipedia) : pour une explication simplifiée.
Intégration Continuela définition par M. Martin Fowler
Déploiement Continu : la définition par M. Martin Fowler

Une partie de l’équipe Soft’it présente au Microsoft DevOps Day !

.equipe main .detail div .profil {
width: 22%;
float: left;
margin-right: 2.6%;
margin-bottom: 2.6%;
border: 1px solid #ccc;
position: relative;
background: #ec6707;
font-weight: 400;
}

.equipe main .profil .photo {
width: 100%;
height: auto;
position: relative;
display: block;
z-index: 100;
border-bottom: 5px solid #ec6707;
}

.equipe main .profil .texte {
margin: 0 auto;
top: 0;
height: 100%;
width: 100%;
padding: 8%;
position: absolute;
z-index: 101;
color: #ec6707;
}

.equipe main .profil .texte h3 {
margin-bottom: 35px;
margin-top: 0;
font-family: « Georgia »,arial;
font-weight: normal;
font-size: 1.375em;
cursor: default;
}
.equipe main .profil .texte span {
text-transform: uppercase;
font-size: .75em;
font-weight: bold;
cursor: default;
}

@media screen and (max-width: 800px) {
.equipe main .detail div .profil {
width: 31.6%;
margin-right: 2.6%;
}
}

@media screen and (max-width: 600px) {
.equipe main .detail div .profil:nth-child(odd) {
margin-right: 2.6%;
}

.equipe main .detail div .profil {
width: 40%;
}
}

@media screen and (max-width: 400px) {
.equipe main .detail div .profil {
width: 100%;
margin-right: 2.6%;
}
}

Chez Soft’it, on aime la technique mais surtout la qualité. Un des axes d’amélioration de la qualité les plus pertinents du moment est la réconciliation/le rapprochement entre le développement et l’exploitation (« ops » en anglais) : le DevOps.

Cela permet de penser un développement dans son ensemble : de la réalisation à la livraison.
Le mouvement « DevOps » a pour objectif de casser les silos existants entre ces 2 étapes, tout en se basant sur une approche agile.


Microsoft et Cellenza organise le « Microsoft DevOps Day« , le 25 novembre 2014 au centre de conférence de Microsoft (Issy-les-Moulineaux).

1 journée pour parler du DevOps et ses origines, puis pratiquer de l’IaaC (« Infrastructure as a Code »), Continuous Delivery (déploiement continu) et du Monitoring. Pour finalement terminer sur le rôle et le futur de Microsoft dans le milieu du DevOps.

Evidemment quelques membres de l’équipe Soft’it seront présents.

Ikbal Benakila

Ikbal
Benakila

Laurent Jacques

Laurent
Jacques

Pier-Lionel Sgard

Pier-Lionel
Sgard

Jérôme Veneziani

Jérôme
Veneziani

Si vous ne pouvez pas y assister, l’équipe tweetera demain et fera quelques feedbacks/résumés des confs dans les jours/semaines à venir. Stay tuned !

window.twttr = (function (d, s, id) {
var t, js, fjs = d.getElementsByTagName(s)[0];
if (d.getElementById(id)) return;
js = d.createElement(s); js.id = id;
js.src= « https://platform.twitter.com/widgets.js »;
fjs.parentNode.insertBefore(js, fjs);
return window.twttr || (t = { _e: [], ready: function (f) { t._e.push(f) } });
}(document, « script », « twitter-wjs »));

Red Gate vs. Giant Octopus (Deploy)

Annoncé au début de ce mois, la société Red Gate – notamment connue pour ses produits d’aide aux DBAs (« SQL Compare » en tête) – a investi pas moins de 2 millions de dollars dans la société Octopus Deploy

Cette dernière édite une solution de déploiement automatique surtout axée .NET.

Qu’est-ce que cela change ?

Déjà, Red Gate retire sa propre solution (Deployment Manager, qui a déjà disparu du site) du marché. Et cela signifie qu’elle va aider ses clients actuels à passer à un nouveau produit … Octopus Deploy évidemment, en envoyant une version gratuitement aux équipes.