The day that I deployed an app in the elevator - DevOps with Lean approach

schedule Apr 9th 04:00 - 04:45 PM place Hall B people 22 Interested

"That day, I was in a big hurry with a time limit ... I had my code done and everything was ready, except for the actual deployment. I had to run out of the door immediately. No choice. I made my mind to do the deploy while on the elevator. The result? Of course it was a success. Thanks to the lean approach, I was able to pursue the deploy with no hassle, with just a click of a button..."

DevOps is not only implementing a set of tools. DevOps is the combination of cultural philosophies, practices, and tools. When It comes to culture, transformation is a key concept and requires full engagement and buy-in from different levels of the organization.

In this presentation, I want to share some DevOps case studies and how we have been evolving DevOps culture over the last years. I will also talk about how DevOps culture is tied connected with Lean philosophy.


Outline/Structure of the Talk

  • About me
  • About CI&T
  • Lean and DevOps
  • Case studies
    • iOS app + .NET API in Azure DevOps
    • Opensource: Drupal and CI/CD pipelines with Jenkins
    • Microservices in Azure DevOps
  • Future and beyond

Learning Outcome

Share experiences about getting started with DevOps and Lean philosophy to start the transformation.

Exchange knowledge about real case studies and how DevOps could be applied for each case.

Target Audience


schedule Submitted 10 months ago

Public Feedback

comment Suggest improvements to the Speaker
  • Carlos Eduardo Papacidero
    By Carlos Eduardo Papacidero  ~  10 months ago
    reply Reply

    Awesome subject to share, we still see teams struggling when the time of deployment comes. It also be great if you share, not only the tools that you used at the "elevator", but also show that today, we have a lot of outstanding tools out there, that made our life easier as well.

  • Weslley Souza Patrocinio
    By Weslley Souza Patrocinio  ~  10 months ago
    reply Reply

    I like these aspects of the submission, and they should be retained:

    • Real case from real world. This is gold.

    I think the submission could be improved by:

    • Exploring the fact that I had confidence to trigger the deploy in the elevator because your DevOps culture and process provided you security enough to engage your decision

  • Liked Wederson Soares

    Wederson Soares - Behavioral Driven Development in DevOps: beyond the development!

    Wederson Soares
    Wederson Soares
    Software Engineer
    schedule 10 months ago
    Sold Out!
    45 Mins

    In DevOps world is always a challenge monitoring the websites and application business and features health when it gets to the production environment. Testing and granting everything is working as expected, after deployed to production, is tough, and sometimes looks impossible.

    During the website/web application development, we usually apply some techniques to achieve that: TDD and Automated Tests, BDD using a gherkin family tool and so on. It is often focused on Development itself and the automation usually finalizes on the last build to production.

    But, what if we leverage the knowledge we acquired during the development and applied that on monitoring the application in a production environment? What if the scenarios could be reused to grant application is still working as expected when the users are really using it?

    Well, it is possible using Behavioral Driven Development techniques and related tools.
    Let me show you how to do it from scratch and present to you a success case of this approach here inside my company, CI&T Japan.

    いつでも, 可能であれば、スピーカーは日本語の用語と英語の用語を併用します。

  • Liked Jean-Baptiste Vasseur

    Jean-Baptiste Vasseur / Masashi Arino / Tsutomu Yasui / Yasunobu Kawaguchi - Fun! Done! Learn! 〜 実験で学び、学びを喜び、喜びを成果につながるふりかえりを体験しよう!

    45 Mins

    Retrospective で Problem -> Solution をだすという KAIZEN のやりかたが、日本ではとても普及している。アリスターコバーンのアイデアに基づくKPT(Keep/Problem/Try)フォーマットは、日本ではデファクトと言っていい。みんな改善が大好きで、改善点が出ないようなふりかえりは意味がないとすら思っている人もいるくらい。


    1. 暗くなること
    2. 改善点は仮説であり、実現可能かどうかはわからないこと
    3. だから、いくらでもアイデアを出せるし議論ができてしまうこと
    4. 同じような課題や改善点が残り続けることで、人々がポジティブになれなくなっていくこと


    Linda Rising の Positive Retrospective というアイデアを発見した。LindaはProject Retrospective の第一原則を参照し、まずこれまでやってきたことを肯定することからはじめ、その上で代替案を出していこう、ということだった。

    そう、私たちはまず、チームがこれまでになにができたかを確認するセレモニーをやらなければならないのだ。Fearless Change における Small Successes パターンのように。Scrumがいうベロシティが意味するチームの能力、現在位置を確認し、完了/実験と成長と学びを喜ぶセレモニーが必要なのだ。チームメンバーがそれぞれ成し遂げたことを確認し、何に喜び、何を学びと感じたのかを共有しあう。

    私たちはこのふりかえりにあたって、壁に貼る、一つのフォーマットを考えた。Fun! Done! Learn! である。このフォーマットの特徴はベン図になっていることだ。複数の要因にかかる要素を示すことができる。例えば楽しく新しいやり方を覚えたのなら、Learn!かつFun!とすることができる。


    当初私たちはDoneではなく、Deliveryという言葉を使おうとした。ただリズムがよりよいDoneを使おうという話になった。Regional Scrum Gathering Tokyo で Hunter Industries の Chris Lucian が実験について講演した。そうだ、実験だ。私たちは Done の中に実験も含めるべきだと気づいた。

    このフォーマットについて Tsutomu Yasui がブログに書いたところ、数週間のうちに日本中で Fun! Done! Learn! が行われるようになった。ブログやfacebookで毎週のように「やってみたよ!」という報告が届いている。Regional Scrum Gathering Tokyo でも Kazuki Mori が Fun! Done! Learn! のボードを作ったところ、貼りきれないほどのポストイットが壁を埋め尽くした。

    私たちはなぜここまで Fun! Done! Learn! が人々にポジティブな効果をあたえるのか、科学的なエビデンスをまだもっていない。しかし、このムーブメントになにか重要な発見があるのではないか?とすら思うようになった。

    DevOps Days Tokyoの場で Fun! Done! Learn! をやることで、この現象が様々な現場でどのような結果に繋がるのかを実験したい。ぜひ、皆さんの職場に持ち帰って実験してほしいと考えている。実験はDone!でありFun!であり、Learn!につながる。まさにアジャイルなマインドセットを Fun! Done! Learn! が呼び起こし、見える化するのではないかと考えている。


  • Liked Mitsuyuki Shiiba

    Mitsuyuki Shiiba - Service Operation Centered Development - サービス運用をまんなかにおいた開発

    20 Mins