【JAWS DAYS2019レポート】至高のCI/CDパイプラインを実現する5つの約束 #jawsdays #jawsug
はじめに
2/23(土)に開催されたJAWS DAYS2019のセミナーレポートです。 内容は整理しているものの、不備がありましたらご了承ください。
前半のテーマ
至高のCI/CDパイプラインを実現する5つの約束
講師
AWS ポジティブなToriさん
大切なこと
最高のパイプラインを手に入れるためのマインドセットとは？
1.パイプラインファースト
- まずはアプリ開発に着手しがち
- 少人数だと特にそう
- CI/CD整備が後回しになり勝ち
- PJで最初にやるべきはパイプライン
- 理想は1発めのDeployからパイプライン通す
- PJへの投資
- 開発の加速を考えると圧倒的な低リスクな投資
- 最初からちゃんとしたものである必要はない
2.自動化されたパイプラインの維持
- ビジネスが変わればアプリは変化する
- 油断するとすぐ自動化できないアプリができる
- オペレーションの自動化が難しいものは開発しない！くらいのマインドが必要
- パイプラインは常にシンプルに保つ
- アプリ都合の複雑性をパイプラインやインフラに押し込まない
- 運用をちゃんと考える
- アプリで吸収したほうがいい場合もある
- DBマイグレーションなど
- アプリ都合の複雑性をパイプラインやインフラに押し込まない
3.柔軟なパイプラインの維持
- PJ進捗によりパイプラインも変化が必要
- 継続的な変化を柔軟に受け入れられるようにする
- 要求変化に対応できる状態を維持する
- ビジネス要件の変化
- policyの変化
- Deploy対象の変化
- パイプラインそのものをコード化・リポジトリで管理
- Iterativeな変更を加えることへの心理的障壁を取り除く
- 検証環境を作って試す
- Iterativeな変更を加えることへの心理的障壁を取り除く
4.パイプラインUXの継続的改善
- パイプラインはメンバーに提供される「サービス」
- パイプライン全体の処理時間の維持・短縮を継続的に取り組む
- 過度な作り込みは避ける
- 黒魔術になりがちwww
5.パイプラインが唯一のリリース手段
- パイプラインを通さないDeployは禁忌
- テストが通らない・Deployコケるは常に起きる
- とりあえず急ぎだから手作業で、は避ける
- 崩壊の始まり
- 使わない人が出てくる
- ビジネスの危機の場合は例外とする
- 崩壊の始まり
後半のテーマ
なぜパイプラインが神なのか
www.slideshare.net
講師
小西 宏樹さん
最近都民になりました！
現場の課題
- 現場の情報
- WEBアプリ開発現場
- マイクロサービス、サーバレス採用
- AWS採用
- モノリシックでも適用可能
- 登場人物
- PO
- 機能開発スピード重視
- ビジネスのスケールアウト
- 機能開発スピード重視
- 密結合なサービス群
- 各チーム
- 運用レベルまちまち
- PO
- 課題
- 無停止Deployが困難
- Deployに時間がかかる
- 手動
- 人的オペレーションによるミス
- その場対応の積み重ね
- 把握不能へ
- 秘伝のタレ化
- 把握不能へ
- Deploy職人が生まれる
- 悪循環
- ビジネス層とのやり取り
神様の仰せのとおりにしていれば・・・
- 5つの約束
- パイプラインファースト
- パイプラインの維持
- 実はパイプラインはあった
- 古くなっていった
- 結局、手動Deployになった
- 一緒に育てていく事が大事
- 古くなっていった
- 実はパイプラインはあった
- 柔軟なパイプライン
- コード管理して修正・作り直しできるように
- UXを継続的にカイゼン
- 自分たちが使って自分たちが楽できる
- 継続的に育てる
- パイプラインは神
失敗から考え・学んだこと
- 絶えずビジネス要求は変化する
- 売るために新機能開発
- 1つ運用面を疎かにすると、技術的負債となりうる
- 後でいいや、、、
- 積み重なる
- 負債へ
- 運用面をおざなりにしない
- 負債へ
- 積み重なる
- 後でいいや、、、
- 透明性が大事
- チーム内で話し合い
- 他のチーム、ビジネス層で見えるところで話し合いをする
- 大事
- 他の人達の視点を取り入れる
- 手戻りをなくす
- チャットなどでもOK
- 誰でも口を挟めるように
- Slackにビルドエラー通知
- このエラーはXXだよ、と言えると良い
- Slackにビルドエラー通知
- 誰でも口を挟めるように
- チャットなどでもOK
- 大事
- ビジネス層の理解を得るために
- 常にビジネス層と議論する
- 簡単にYESと言わない
- ちゃんと説明できるように資料作る
- 見える化する
- 普段からメトリクス取る
- Opsをおざなりにすることでのリスクを数値化
- 普段からメトリクス取る
CloudNativeに向けて
- CNCFが提唱
- 日本語訳がでた！
- 疎結合
- マイクロサービス
- 回復性
- Infurastructure as code
- 管理されている
- イミュータブル
- 副作用がないコード
- 観測型
- モニタリング
- イミュータブル
- 堅牢な自動化
- 神！！！とする
- 大きな変更を最小限の労力で
- 神の恩恵！！！！
- 疎結合
- 日本語訳がでた！
- 全てはパイプラインと共に成長する
感想とまとめ
ポジティブなToriさんは、ラスベガスから雪のため到着できなくなったため、急遽動画になったとのことです。ウェビナーみたいでしたが、声が非常に聞きやすく大変勉強になりました。
プロジェクトが始まったらまず最初にパイプラインを作るべし！という考え方はなかなか実践できません。大体アプリケーションが動くようになってステージング環境などにデプロイする必要が出てきてから作り始めることがほとんどだと思います。（少なくとも私の現場ではそうです）開発のリーダーやその上の人たちが、CICDを整えることのメリットの大きさをどれだけ重要だと考えているかも大切だと思いました。組織の文化にも関わることだと感じました。
現場では、パイプラインを神として崇めることで、手動での作業を一切許さないという運用ルールが必要です。運用ルールを整えて、ルールを徹底することは大変ですが、それ以上に恩恵を受けることができるのだと思います。
パイプラインを神とする考え方。アプリ開発を優先して、途中からCI/CD入れようとしてる自分のチームはまさにアンチパターンなのだな。仕組み作りの重要性を役員や上司にもっと理解してもらうようにする努力が必要だなあ。がんばろう。#jawsdays #jd2019_d
— Yokoyama Hironori (@yokoyantech) 2019年2月23日
今年は自分の開発チームに CICD の仕組みと、Dockerによるコンテナ化を進めていきたいと思いました。
