Day 1

カオナビ自動テストとかの話

顧客ごとに本番環境にログインして環境構築していたけど
社内Webアプリを立ち上げて手動作業をなくした
そもそも本番環境にログインして構築する設計。。。（なんでこうなってたのだろう）
シェルで手作業リリースしなければいけない運用だった

E2Eテストについて

技術スタック
- TestCafe, TypeScript
  - https://tech-cci.io/archives/5426
- gitlab ⇒ docker
テスト範囲
- 既存テスト安定化、広く浅いテスト
- インシデント再発防止のテスト
- 手動で辛いテスト
課題
- 特定の環境でしか動かない
- 同時実行はできない、開発もできない
- データが壊れると大変。。。≤これほんとそう
- リリース前にテスト実行されてない、リリース後に検知できない
- 不安定なので失敗したり成功したりする ⇒ Flakey
  - テストなのか修正したものなのかわからない
  - 地道な調査・改善で対応できるようになった、今は月に１回とか
  - テストの安定性をなるべく優先している？
- 大量にメモリを使用していた
- 同様の修正があちこちであった
  - PageObjectモデル、E2Eでは有名なデザインパターンを設計しライブラリ化した
- データ量が増えて重くなる
  - データ量を削減してダイエット、広く浅く
- E2E学習コストが発生する
  - ライブコーディング、ペアプロ、テストSaaS？、ドキュメント化
- 実行環境の街が発生するので自動スケールするようにするか検討中
感想
- やはり↑の課題が多く、対応するのに1年はかけて対応する必要がありそう。ついでにやるなんて無理
- PageObjectのデザインパターンは初めて聞いたので知れて良かった

DevOps論文100本ノック

発表者
- アジャイルコーチの人、筑波大学とかでアジャイル開発を教えている人
- name: kyon_mm
- スクラムの人
探し方
- survey論文を探す
- devops, survey, google scholar, ACM Digital Library, IEEE
- [devops survey]がキーワード
紹介する論文はこれ ⇒「A survey of DevOps Cencepts and Challenges」
最もカバレッジの高い論文でDevOpsの定義とは？
- 自分の考え ⇒ 開発と運用との効率的な連携
- DevOpsとは新しいバージョンのソフトウェアを継続的に自動配信し、その正確性と信頼性を組織内の協力的かつ多角的な取り組み
- Devops ⇒ is a ⇒ culture of collaboration ⇒ based on sharing ⇒ knowledge tools processes and practices.
- 書籍数も伸びている
DevOps ⇒ Agile/Lean ⇒ 申請性の高いリリースプロセス　（納得感！！）
Backtoryの話
- モノリスからMSAに変更するときにDevOpsいなければ無理だったという話
カオスエンジニアリング
- 分散システムは難しい。Netflix本家が書いている。Netflixが苦労している話
MSAのための実装パターン
- IBMの人がPLoPに出したらしい
感想
- そもそもDevOpsに関する論文そんなにあるんだというのが発見
- ようはググれということ
資料
- https://dl.acm.org/doi/10.1145/3359981

Day 2

Keynote Chris Lucian: Interview with Q&A

DevOpsDays Tokyo 2022

Mob programmingの話

https://qiita.com/TAKAKING22/items/31e027dfb6ea8b1a8d69

1つのコンピュータで4人でコーディングしている

1時間を1ヶ月に一回くらい

デザインパターンを使ってみんなで実装。お互いに同意を得て実装を進めている。

コンクリートディスカッションしている

オフラインだと大きいディスプレイ2つでみんなでコーディング、コーディングする人と指摘する人を分けて実施、メンバー教育にも良いしお互いに尊重できれば楽しそう

月1とかで対面で行うと楽しそう

オンラインでもやってる

オンラインは少し難易度高そう

プロジェクターとかに移しても良さそう

Driver

Navigator

https://github.com/willemlarsen/mobprogrammingrpg

https://github.com/willemlarsen/mobprogrammingrpg/blob/master/Mob Gallery.pdf

ナビゲーター

逆に、一人でコーディングするというのを業務でやるというのがわからなくなってきた。だいたいペアかモブ作業。
一人一人に作業分解するとか、数日後にシニアに指摘を受けてやり直すとかとか・・・いろいろ実は無駄

⇒ これをやっていきたい。。。

Kohsuke Kawaguchi - Flaky test対策の最新動向

7つに1つはFlakyなテストが存在する(by google)

発表者
- Jenkins作った人
- Launchable Inc

なぜよくないのか

コードには問題ないけどテスト失敗してしまう

火事は起きていないのに非常ベルが鳴るようなもの

これが常識になってしまうと本当に火事が起きたときに非常に危険

通ったと思ったのに失敗で時間が取られる

Flakyテストの起こる要因

メモリがたくさん使うとFlakyが起こることが比例的に増えた

全体のテストをやったときによく起こる

時刻に関連

グローバルなステートにアクセスしたとき

⇒ これはよくある、シングルトンとかで書かれてると別テストで変更されたときに死んでしまう

Google ⇒ 7つに1つ

GitHub ⇒ 100回連続で失敗するのは1%未満なのでここを解決すれば効果がある

What’s been done?

Big Picture

Keeping builds green: テストがgreenであること（成功すること）を維持する
Measuring flakiness: 継続的に記録する
Escalating flakiness: フィードバック

Simple solutions

リトライ！リトライ！リトライ！
- でも大抵リトライしている
時間が起因するのであればシステムの時間自体を変えてあげる
別のVM上でテストをリトライする（コストが高い気がする）
Flakinessを隠してしまう
FBを遅らせる
pre-mergeのテストでFlakyテストは無視する
隠すのも嫌、無視するのも嫌
- ⇒ 現実的ではない、コストに見合わない、作成したテストが別開発者でたまったものではない

Really native approach (現実的な原始的なやりかた)

Flakyのテストの特定の仕方

同じコードを何度も実行して結果が異なればFlakyとする
ネットワークに問題があるとき

常に記録をしていて、失敗回数が多ければFlaky、少なければよりFlaky（希少）

Bayesian inference by facebook

Naive solution (わかりやすい)

記録をする

誰が変えたかを記録する

Architechtural approach

フレームワーク自体を変えた

DIもテスト、設計をしやすくしたから

アーキテクチャが大事

Flakiness’s summary

粛々とビルドし続ける
マスクされるFlakinessを計測し続ける
検出されたFlakinessを周りに伝達して協力して解決していく
- 自分だけではないので周知する取り組みが大事
資料 https://github.blog/2020-12-16-reducing-flaky-builds-by-18x/ https://blog.cybozu.io/entry/2020/12/23/100000

食べログのソフトウェアテスト自動化デザインパターン

食べログのソフトウェアテスト自動化デザインパターン - DevOpsDays Tokyo 2022

発表者

食べログの人, kakaku.com
食べログシステム本部技術部
@hagevvashi

Contents

課題背景

QA組織が17年間いなかった
コード修正後のフィードバックが遅い
テストが再利用できない

テスト自動化基盤

テストランナー、Cucumber, selenium ⇒ chrome, firefox,

いきなり１００％目指さない 1sprint 95%を目指す 2sprint 徐々に上げていく
容易にテストを追加できるFWを選定 FW設計、ステップによりがちなテストをどう設計していくか Adapterパターン Click Screenshot ⇒ base ClickAdapter ⇒ ClickAdapterScreenshot PageObject ComponentObject ページ、UIパーツごとに作成効率的なテストの解決策

JSONデータ駆動テスト
StepにWait処理を書かない
- page.prepare()で待つ
- wait(1000)などを書かない ⇒ anti pattern
ログインタグを使う
- ユーザの種類もタグを使って分ける
資料 https://www.selenium.dev/ja/documentation/test_practices/encouraged/

デプロイ頻度を高めるために私達にできることは一体何があるだろうか？

デプロイ頻度を高めるために私達にできることは一体何があるだろうか？ - DevOpsDays Tokyo 2022

発表者

Splunk
Observability専門のエンジニア
スキーが趣味
- 3m飛んで足を骨折している

デプロイ頻度が重要な理由

前職の話
- 2週間に1回のリリースサイクル（Software in 30 daysは30日だから悪くない）
- 頻度は悪くない
- 手動でコマンド叩いてリリース
- 事件が起きる
  - ブラウザ(IE)起因のサービス停止
課題テストでカバーするのは難しいマージよりも分離は難しい <aside> 🔥 重要なことはデプロイ頻度ではなく、小さい単位でデプロイすること </aside> ⇒ 失敗したときに戻しやすい ⇒ 確認が簡単

デプロイ頻度をブロックするものは何か

QAプロセスの不具合を見つけるためのプロセスはあまり不具合が見つかることは少ないのでは？
レビュー
- コピペでソースコード移していないか
- テストコードが正しいか
- ⇒ 品質を担保するレビューはしていない
品質判定会議で品質が改善されることは少ない
デプロイフローが長い
- AmazonはNightly buildが朝に終わらなかったからMSAを提唱した
- モノリシックの限界を感じた
コードの変更範囲が大きい
- 大きいほど影響範囲が大きい
- リファクタリングを優先する
  - そもそもできない、リファクタを工数に考えていないところもある
  - リファクタしたくても既存ファイルが多すぎて工数がかかるからしない事が多い
シンプルに怖い
- 何が起こるかわからん
- 怖いことを回避するには小さくデプロイするしかない
- でも怖いことは怖いので**可観測性(=Observability)**が重要（⇒Splunkに働いてる理由だったりする）
- エラーバジェットが大事
  - 100% - SLO（99.9%） = 0.1%

「毎日複数回デプロイ」が実現された先

レビュー観点2つ
- モニタリング項目はなにか
- ロールバックできるか
SLO 100%ではないことを前提とする
- 障害が起きても良いような設計をする
- 外部サービスが落ちたときに、Callback or Retryする機構になっているか？`
フルサイクルエンジニアリング
- 人材に専門性を作らない (= 他責になる)
実験的デプロイ
カオスエンジニアリング Chaos Engineering
技術やビジネスをチャレンジできる環境
資料 LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear) Chaos Engineering 5分で学ぶ: カオスエンジニアリングの説明書 Splunk Observability Cloud無料トライアル | フルスタックのオブザーバビリティが14日間無料
感想結構ためになる公演と思ったのと同時に今は毎日デプロイできてるしある意味でDevOpsできているのかもしれない。意外と自分たちが目指しているものはモダンすぎるのかもしれない。〇〇だからレガシー！という判定はあまりよくなくて選択肢として知っておくのが良いのかなと思った。

右手にDevOpsハンドブック左手にクックブック

https://speakerdeck.com/recruitengineers/devopsdays-takahashi

Kenote マシュースケルトンとのQA 60mins

チームトポロジー書いた人

マシュースケルトンとアレックスの対談

アウトソースするのは良いのか悪いのか
- アウトソースの種類による、チームにとって重要でないものならば良いのかな？
チーム全体で変化に責任を持てるかどうかである
- 専任制を強く持たせると上手くいかない気がする、ソフトウェアエンジニアリングが大事、だから今求められている
まさにモブプロは全員でチームに責任が存在している、だから上手くいく、大変だけどね
- レビューがすくなくなるからビルドが少なくなる、
- 一緒に仕事をすることが大事
Stream Aligned team以外に何がある?
- e2eでチームに責任を持つチームがある
- enabling team（可能にするチーム）
認知不可を測定する
enabling teamは組織や専門スキルを持っていて、チームに共有、支援していく。
- 2日とか1週間ケアをする
- これを定期的にやる？
どちらかというとチームトポロジーは経営陣、トップが知っているべき、学習したほうが良い
- エンジニアが提案するにはどうしたらよいのか？
  - 組織の人全員と話をする必要がある
チームトポロジーはチームのためのデザインパターン、メタパターンである
Q&A
チームトポロジーを使って変わった事例は？
- 会社のHPに事例が載ってる
- ジムの会社（非IT）
- チームトポロジーは全般的に適用できる
  1. チームファーストというアプローチを取った
  2. ウェブサイトの要素を洗い出した
  3. 別個のリストに洗い出し
  4. チームトポロジーを適用する
  5. アンケートなどで認知不可の度合いを測定する
  6. 高ければ変更していく
戦略的にチームアサイン変更するのはどうだ
- 健全に変更するパターンがある（別本）
- スローにチーム変更していくことは必要（同意！）
- 破壊することはダメ
チームトポロジーを使って何かしらの変化を促す旗振り役はどういった人たちが適任なんでしょう？
- エグゼクティブレベルの人も良い
- エンジニアの上位職も良い
- 全体的に理解している上の人が必要、アーキテクトを知っているべき人も必要
- 複数のレベルの部長職が必要になる