Day 1
カオナビ自動テストとかの話
- 顧客ごとに本番環境にログインして環境構築していたけど
- 社内Webアプリを立ち上げて手動作業をなくした
- そもそも本番環境にログインして構築する設計。。。（なんでこうなってたのだろう）
- シェルで手作業リリースしなければいけない運用だった
E2Eテストについて
- 技術スタック
- TestCafe, TypeScript
- 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に関する論文そんなにあるんだというのが発見
- ようはググれということ
Day 2
Keynote Chris Lucian: Interview with Q&A
Mob programmingの話
1つのコンピュータで4人でコーディングしている
1時間を1ヶ月に一回くらい
デザインパターンを使ってみんなで実装。お互いに同意を得て実装を進めている。
コンクリートディスカッションしている
オフラインだと大きいディスプレイ2つでみんなでコーディング、コーディングする人と指摘する人を分けて実施、メンバー教育にも良いしお互いに尊重できれば楽しそう
月1とかで対面で行うと楽しそう
オンラインでもやってる
オンラインは少し難易度高そう
プロジェクターとかに移しても良さそう
Driver
Navigator
ナビゲーター
逆に、一人でコーディングするというのを業務でやるというのがわからなくなってきた。だいたいペアかモブ作業。 一人一人に作業分解するとか、数日後にシニアに指摘を受けてやり直すとかとか・・・いろいろ実は無駄
⇒ これをやっていきたい。。。
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を周りに伝達して協力して解決していく
- 自分だけではないので周知する取り組みが大事
- 資料
食べログのソフトウェアテスト自動化デザインパターン
発表者
- 食べログの人, kakaku.com
- 食べログシステム本部技術部
- @hagevvashi
Contents
課題背景
- QA組織が17年間いなかった
- コード修正後のフィードバックが遅い
- テストが再利用できない
テスト自動化基盤
- テストランナー、Cucumber, selenium ⇒ chrome, firefox,
- いきなり１００％目指さない
1sprint 95%を目指す
2sprint 徐々に上げていく
- 容易にテストを追加できるFWを選定
- JSONデータ駆動テスト
- StepにWait処理を書かない
- page.prepare()で待つ
- wait(1000)などを書かない ⇒ anti pattern
- ログインタグを使う
- ユーザの種類もタグを使って分ける
FW設計、ステップによりがちなテストをどう設計していくか
Adapterパターン
Click
Screenshot
⇒ base ClickAdapter
⇒ ClickAdapterScreenshot
ComponentObject
ページ、UIパーツごとに作成
効率的なテストの解決策
- 資料
デプロイ頻度を高めるために私達にできることは一体何があるだろうか？
発表者
- 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
- 技術やビジネスをチャレンジできる環境
- 資料
- 感想
結構ためになる公演と思ったのと同時に今は毎日デプロイできてるしある意味でDevOpsできているのかもしれない。
意外と自分たちが目指しているものはモダンすぎるのかもしれない。〇〇だからレガシー！という判定はあまりよくなくて選択肢として知っておくのが良いのかなと思った。
右手にDevOpsハンドブック左手にクックブック
Kenote マシュースケルトンとのQA 60mins
チームトポロジー書いた人
マシュースケルトンとアレックスの対談
- アウトソースするのは良いのか悪いのか
- アウトソースの種類による、チームにとって重要でないものならば良いのかな？
- チーム全体で変化に責任を持てるかどうかである
- 専任制を強く持たせると上手くいかない気がする、ソフトウェアエンジニアリングが大事、だから今求められている
- まさにモブプロは全員でチームに責任が存在している、だから上手くいく、大変だけどね
- レビューがすくなくなるからビルドが少なくなる、
- 一緒に仕事をすることが大事
- Stream Aligned team以外に何がある?
- e2eでチームに責任を持つチームがある
- enabling team（可能にするチーム）
- 認知不可を測定する
- enabling teamは組織や専門スキルを持っていて、チームに共有、支援していく。
- 2日とか1週間ケアをする
- これを定期的にやる？
- どちらかというとチームトポロジーは経営陣、トップが知っているべき、学習したほうが良い
- エンジニアが提案するにはどうしたらよいのか？
- 組織の人全員と話をする必要がある
- チームトポロジーはチームのためのデザインパターン、メタパターンである
- Q&A
- チームトポロジーを使って変わった事例は？
- 会社のHPに事例が載ってる
- ジムの会社（非IT）
- チームトポロジーは全般的に適用できる
- チームファーストというアプローチを取った
- ウェブサイトの要素を洗い出した
- 別個のリストに洗い出し
- チームトポロジーを適用する
- アンケートなどで認知不可の度合いを測定する
- 高ければ変更していく
- 戦略的にチームアサイン変更するのはどうだ
- 健全に変更するパターンがある（別本）
- スローにチーム変更していくことは必要（同意！）
- 破壊することはダメ
- チームトポロジーを使って何かしらの変化を促す旗振り役はどういった人たちが適任なんでしょう？
- エグゼクティブレベルの人も良い
- エンジニアの上位職も良い
- 全体的に理解している上の人が必要、アーキテクトを知っているべき人も必要
- 複数のレベルの部長職が必要になる