Behavioral Driven Development in DevOps: beyond the development!

schedule Apr 9th 02:00 - 02:45 PM place Hall B people 21 Interested

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.

スピーカーは日本語が分かるから、セッションコンテンツの日本語版もあります。
いつでも, 可能であれば、スピーカーは日本語の用語と英語の用語を併用します。

 
 

Outline/Structure of the Talk

  • About me and CI&T
  • Brief Introduction to BDD
  • How to apply this as a monitoring tool
  • Tools and Techniques we can use
  • Case study:
    • Using Behat to monitor a website
  • Other uses and suggestions

Learning Outcome

Leverage the use of BDD artifacts.

Learn an alternative way of monitoring applications in production.

Target Audience

Everyone

schedule Submitted 7 months ago

Public Feedback

comment Suggest improvements to the Speaker
  • Eliseu Silva
    By Eliseu Silva  ~  7 months ago
    reply Reply

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

    • ...

    I think the submission could be improved by:

    • ...

    • Liked Gene Kim
      keyboard_arrow_down

      Gene Kim - Lessons Learned Since The Phoenix Project

      Gene Kim
      Gene Kim
      Founder
      Tripwire
      schedule 9 months ago
      Sold Out!
      60 Mins
      Keynote
      Beginner

      I’ve learned so much since The Phoenix Project came out in 2013. In this talk, I will share my top learnings while co-authoring The DevOps Handbook with Jez Humble, Patrick Debois, and John Willis and the recently-released Accelerate with Dr. Nicole Forsgren and Jez Humble. I’ll talk about the latest findings from the State of DevOps Report, the true importance of deployment lead times, how DevOps truly transforms the lives of Dev and Ops, what I learned about Conway’s Law, and how DevOps is a subset of dynamic learning organizations, of which Toyota is the most famous. This project was one of the most fun and rewarding adventures of my life, and I want to share some of my biggest a-ha moments!

    • Liked Alex Papadimoulis
      keyboard_arrow_down

      Alex Papadimoulis / Sho Sato - Welcome to DevOpsDays 2019!

      30 Mins
      Keynote
      Beginner

      Sho and Alex will discuss the theme of this year's event, provide some logistic info, introduce the sponsors, and get everyone fired up for two days of DevOps!

    • Liked Jean-Baptiste Vasseur
      keyboard_arrow_down

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

      45 Mins
      Workshop
      Beginner

      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を生み出していく。

      当初私たちは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 Edward Thomson
      keyboard_arrow_down

      Edward Thomson - How We Moved 75,000 Microsofties to DevOps in the Cloud

      45 Mins
      Talk
      Beginner
      How do you migrate over 75,000 of the most demanding software engineers from infrastructure built up over decades of high-intensity work into a common engineering system based on modern software development technologies and best practices? This is exactly the challenge faced by Microsoft as they moved to their One Engineering system, a globally distributed 24x7x365 service hosted in Azure DevOps. Edward Thomson will explain how we did it, the lessons that we learned along the way, and some of the technical challenges that still remain.
    • Liked Mitsuyuki Shiiba
      keyboard_arrow_down

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

      20 Mins
      Talk
      Beginner

      サービス運用をまんなかにおいた開発についてお話します。

      僕は2010年から楽天の大阪支社でウェブアプリケーションエンジニアとして仕事をしています。僕のいる部署は中規模から小規模のたくさんのサービスを担当していて、1つのチームまたはグループでサービスの開発と運用の両方を担当しています。

      サービスの開発と運用の両方を担当しているため、僕らはサービスの運用のことを常に考えながら開発に取り組んでいます。運用のことを考えずに開発をすると全てが自分たちに跳ね返ってくるからです。

      このセッションでは、サービスの運用をまんなかに置いて開発をするときに、どのようなことを考えるか、また、どのように他のチームや組織と向き合うか、について自分の経験を元にお話したいと思います。

      資料は英語ですが、セッションは日本語です。

    • Liked Geovanne Bertonha
      keyboard_arrow_down

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

      Geovanne Bertonha
      Geovanne Bertonha
      Solutions Architect
      CI&T
      schedule 7 months ago
      Sold Out!
      45 Mins
      Talk
      Intermediate

      "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.