Formation continuous delivery

[Radwane]

Hey tous,

Je suis un grand fan de l'approche DevOps et toute approche en générale qui permet de raccourcir le feedback (bon c pas encore ça dans la communauté .Net, mais c'est peut être une nouvelle mission pour Alt.net :p ), du coup j'ai sauté sur l'occasion de hoster une formation de KickStart Academy, 

Bref si le sujet "Continuous Delivery" vous intéresse. Il y a nos amis de Kickstart Academy qui viennent faire une formation à Paris le 25 & 26... Si ce genre de sujet vous tiens à cœur n'hésitez pas à vous inscrire ou partager et relier la news :)

Merci à vous 

Bonne journée,

Rad

[Nieve]

Salut Radwane-

Puisque mon équipe est en train de mettre en oeuvre de CD, je peux vous conseiller fortement a être super prudent avec le CD, car il s'agit d'un outil qui peut mal utiliser - même (et peut être surtout) si le passage au CD est un succès. D'abord, il faut avoir l’œil pour trouver tous les problèmes que le CD va faire surfacer et puis les traiter! Le Continuous Delivery est malheureusement devenu un sort de tampon technique et en train de perdre sa raison d’être. Ce n'est pas de tout le bute, mais seulement un moyen.

Et puis, si on réussi avec le CD mais le business n'est pas prêt, on peut se trouver dans une situation hyper tendu. L'optimisation ciblée peut faire plus de mal que de bien a votre flow.

Désolé si ca fait trop donneur des leçons, mais en ce moment je suis a fond dans le sujet et je commence a voir et comprendre l'importance de tous ces processus et la façon dont on les utilise.

n

[Nicolas Frelat]

Radwane, merci pour l'info sur la formation.

Et +1 pour aborder le Continuous Delivery sur Alt.NET !

Nieve, le processus de validation de ce qui est déployé en production reste central. Il y a des milieux qui ne sont pas compatibles avec les évolutions qui sortent du four en production. Pour ma mise en œuvre du CD, j'aimerais que la partie dev => envs de test soit très simple et rapide et qu'en même temps la partie env de validation => production passe par une validation plus formelle (voire avec une réversibilité si possible).

Nicolas F.

--

---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "altnetfr".
Pour vous désabonner de ce groupe et ne plus en recevoir les messages, envoyez un e-mail à l'adresse parisaltnet...@googlegroups.com.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[maxime....@gmail.com]

Salut,

Radwane, c'est toi qui organise la KickStartAcademy Valtech avec Seb Rose ?  la classe  :-)

J'avais essayé de la vendre à mon responsable, mais bon, comme j'ai fait IDDD, c'est pas passé....  :-(

Je vais quand même retenter et éventuellement y envoyer quelqu'un d'autre....

Moi aussi je suis super intéressé par le sujet et j'aimerai qu'on en discute lors de meetups.

Il y a Houssam qui avait créé ce groupe, mais il n'y jamais eu de meetup d'organisé... http://www.meetup.com/Paris-Continuous-Delivery/

Je comptais le relancer sur le sujet. On peut tous lui mettre la pression  :-)

Sinon, je suppose que vous êtes au courant, mais au cas où ça serait passé à la trappe pour certains, Thoughtworks, la boîte de Jez Humble et Martin Fowler (pour ne citer qu'eux) a rendu gratuit (et bientôt opensource) leur outil de Continuous Delivery, Go : http://www.go.cd/

Voilà une petite vidéo d'intro : http://www.go.cd/2014/03/10/go-webinar-recording.html (et y'en a plein d'autres dans les ressources : http://www.go.cd/community/)

Le principe de pipeline qui mixe du process automatisé et manuel, répond à la demande soulevée par Nicolas, par contre, le rollback n'est pas dans leur philosophie (ils s'expliquent pourquoi)

Voilà, c'est tout pour l'instant !

Maxime

[Nicolas Frelat]

Maxime, merci pour l'info sur Go :-)

[Nieve]

Nicolas- désolé, je suppose que j'ai mal expliqué ce que j'ai voulu dire par processus. Moi je parle plutôt de processus de travaille plus générale - le processus dans le sens de "lean" (plutôt le Toyota lean). Il y a énormément de littérature sur le sujet et il s'agit d'un sujet extrêmement complexe donc j'irai pas plus loin que ça. Le CD en tout cas n'est pas un but en soi mais une méthode. Si vous arriver a mettre en prod des nouveaux "features" sans que le business soi prêt le processus de l'entreprise ira pas bien, ce qui est beaucoup pire que n'est pas réussir le CD. Le CD est la aussi pour faire remonter les problèmes qui sont cachées dans le processus du développement de vos équipes. Continuous Delivery ne doit pas être un sujet technologique qui ne concerne que nous les développeurs et les geeks... 

Quant a GO- perso, je préfère de faire tout par des scripts- c'est la seul raison d'avoir toute l'histoire du processus dans mon version control (git). Comme ça en plus on peu l'utiliser pour mettre en oeuvre une environnement locale aussi, et tester le processus.

[Nieve]

D'ailleurs, l'un des raisons d’être de CD est de forcer les développeurs a être plus prudents et incorporer l'assurance de qualité dans leur processus quotidien. Si on essaye de faire de continuous delivery sans pouvoir augmenter la qualité de code et de produit, on fait de 'firefighting' constant- ce qui n'a rien avoir avec le CD.

On Wednesday, 12 March 2014 20:54:38 UTC, Nicolas F. wrote:

[Radwane]

Hello hello,

Content que le sujet intéresse :) 

@Max oui je me suis occupé du host de l'event :), sinon je peux avoir des réductions si ça t'intéresse...

Sinon @Nieve je ne sais pas si tu parles de "continuous delivery" ou "continuous deployment" ? En tout cas perso, je penses que savoir déployer en un clique est aujourd'hui indispensable dans certaines organisations (environnement agile ? Web ? Mobile...) et que l'infra as code doit être mieux maîtrisé pour les ops (2 jours pour monter une VM ou un environnement de dév ou de recette... Sans être sûre que ça va marcher, ne me paraît pas une situation acceptable). Sinon pour moi le CD en générale est l'aboutissement d'une approche XP maîtrisé, donc oui il va de soit que la qualité de code/livrable doit être haute et que la valeur ajoutée d'une livraison doit être pertinente (CD avec 2 semaines de recettes pour validation et correction de bug est effectivement un non-sens).

Pas de Silver-bullet, mais juste une approche concrète de l'optimisation du feedback et du time to market.

Après comme dans tout, il faut donner le temps au temps et surtout être Kaizen ^^

Bonne journée,

Radwane

PS : N'hésitez pas à relayer l'infos :)

[Florent Pellet]

C'est un peu tard vu que toutes les places sont déjà vendus, mais si vous avez une place pour Mix-It (Lyon), nous l'allons expérimenter pendant les 2 jours de l’événement grandeur nature (http://www.mix-it.fr/session/362/crafting-workshop).

D'ailleurs si des personnes sont intéressés par l'organisation ou pour nous donner des retours d'expériences sur une stack JS, on est preneur :)