1CI/CDを使い倒して数段上のソフトウェア開発しよう#devsumi #circlecijp
View Slide
2CI/CD 戦国時代Google GCP Cloud BuildMicrosoft Azure PipelinesAWS CodeBuild GitHub Actions
3CI/CD 戦国時代
4最初の疑問なぜCI/CDへの関心がこれほど高まっているのか？
5自己紹介:Kim, Hirokuni (金 洋国)- 元CircleCI 開発者- CircleCI Japan TechLead- CircleCI SRE
6モチベーションについて
7このセッションの基本の流れWhatWhyWhy NotBeyond
8宣伝 (会社)● 日本語サポート● ドキュメントの日本語化● ユーザーコミュニティーCircleCI初の海外支社@CircleCIJapanFB Community Group
9CI / 継続的インテグレーション
10What is CI?
11その前に確認もちろんテストは書いてますよね？
12なぜテストを書くべきか● 何度も同じ手順を繰り返さないといけない● 人の目や手に頼ると必ず見落としが発生する
13なぜテストを書くべきか● 何度も同じ手順を繰り返さないといけない● 人の目や手に頼ると必ず見落としが発生するそれコンピューターにやらせようよ！
14CIとはテストを自動で実行する仕組み開発者のコード変更に対して● 常に● 同じ環境でテストを実行してくれる
15CIとはテストを自動で実行する仕組み開発者のコード変更に対して● 常に● 同じ環境でテストを実行してくれる※ テストは自分たちで用意する必要がある
16Why CI?
17ただテストを書くだけでは不十分● テストがあるけど実行し忘れた● 昔書いたテストが壊れていて動かない● テスト結果が環境依存
18ただテストを書くだけでは不十分● テストがあるけど実行し忘れた● 昔書いたテストが壊れていて動かない● テスト結果が環境依存テストの信頼性がない
19問題: テストの実行忘れ● リリース前にテストをしわすれる● バグを見落とす● 修正でリリースが遅れる
20解答: 常にテストを回す● GitHub (VCS)の変更をCI/CDが検知● 全変更に対してテスト実行
21問題: テストが壊れてしまう● 古いテストが壊れている● テストが悪いのかコードがわからない
22解答: 壊れたテストを素早く検知● テストが壊れた時点で検知● 直さないとマージできない (後述）
23使われていない自動化は壊れていく“サイボウズを支える CircleCI”より
24問題: テスト結果が環境依存僕のマシンだとテスト通ってます(｀・ω・´) ｷﾘｯ
25例: テスト環境の差異による問題CreateNewBook古いBookレコードCheckNewBookCreated テストPassバグ FalseNegativeテスト対象テストローカルDBに残っているデータのせいでCreateNewBookのバグを検知し損ねる
26解答: CIを唯一のテスト環境にする● 毎回同じテスト環境が構築される● まっさらな環境でテストを実行● いつ実行しても同じテスト結果になる
27CIの目的テストの新陳代謝を高めて信頼性をあげる
28Why NOT CI?
29CI導入を妨げる問題● テストがない● メンテナンス
30問題: テストがない● CIを始めたい● でも実行するテストが存在しない● テスト文化の布教にはコストと時間がかかるCIを導入する上でいちばんやっかいな問題
31テストがない状態からCIを始める5ステップStep 1: お好みのCI/CDツールを選ぶStep 2: タスクの自動化Step 3: 可視化するStep 4: マージブロックStep 5: テストを追加していく
32Step 1: お好みのCI/CDツールを選ぶ
33ステップ2: 様々なタスクを自動化しようテスト以外のタスクを自動化● 構文チェック（linting)● カバレッジ計測● 循環的複雑度のチェック● ドキュメントの自動生成
34ステップ3: 可視化しようCI結果を可視化しよう● ステータスバッジ● ダッシュボードの作成● メール・チャットでの通知
35CIやってる感が出てくる”お、俺たちCIしてるっぽい”
36Step 4: マージブロック有効化マージするための条件をブランチごとに指定できる機能● CIが通らないとマージできない● 管理者しかマージできない● Force Push禁止● Etc, etcCircleCIが通らないとマージできない
37Step 5: テストの追加少しずつテストを追加していく● ユニットテストはとりあえず後回し● 最も大事なビジネスロジック● この時点では無理は禁物....
38CI導入を妨げる問題● テストがない● メンテナンス
39問題: メンテナンス● CI/CDツールのメンテナンスは大変● 通常専任のエンジニアが必要● CircleCIのようなクラウド型がおすすめ
40クラウド型 VS オンプレミス型クラウド型 オンプレミス型AWS CodeBuild CircleCIGCP Cloud Build Travis CIJenkinsConcourse CI
41CIのまとめ● テストの信頼性と品質を向上させる● テストがなくてもCIは始めれる● できる自動化からはじめよう● クラウド型のツールで運用コストを下げる
42Beyond CI
43開発フローコードをPush
44開発フローコードをPush CIでテスト
45開発フローコードをPush CIでテスト masterへマージ
46開発フローコードをPush CIでテスト masterへマージ自動
47開発フローコードをPush CIで自動テスト masterへマージ自動リリース手動
48CD / 継続的デプロイメント
49What is CD?
50CDとは？Continuous Deployment (継続的デプロイメント)自動でステージング・本番環境へデプロイContinuous Delivery (継続的デリバリー)常にリリース可能な状態を維持する
51Continuous Delivery (継続的デリバリー)リリース作業に人間の意思が介在するコードプッシュJARファイルCIDockerイメージステージング本番環境人間が決定CDContinuousDelivery
52Continuous Deployment (継続的デプロイメント)リリースに人の意思が介在しないコードプッシュJARファイルDockerイメージステージング本番環境ContinuousDeliveryCDCI CDContinuousDeployment
53Why CD?
54リリース後に発覚する仕様バグ● リリースして実際に使ってみた● ユーザーの要求を満たしていない● 仕様が全然間違っていた
55なぜこのようなことが起こるのか本当に必要な機能はクライアント/ユーザーにも使ってみないとわからない
56解答: フィードバックループを使おう● 細かい単位でリリースする● フィードバックを早めに得る● カイゼンする
57CDなしだとだとループが回らない● リリースの許可が必要● ヒューマンエラーフィードバックループが回らない
58CDなくしてフィードバックループなしNo CD, No Feedback Loop
59最初の疑問なぜCI/CDへの関心がこれほど高まっているのか？
60Why NOT CD?
61Why NOT CD?● 技術的な問題● 組織的な問題CDを始める上での2つの問題
62CD導入の技術的な問題● エンタープライズなアーキテクチャー● レガシー (技術的負債が多い)アーキテクチャーそもそもシステムがCDに向いてない
63CD導入の組織的な問題CDするには不向きな組織● 官僚的な組織● 失敗に対する許容が低い組織
64解答: 時間をかけてアップデート● サービスの疎結合● 徐々にモダン化● チームのDevOps化を進めるCD導入の銀の弾丸はない
65新システムにはまずCI/CDを導入しよう家永 英治さんのブログより
66CircleCIでの事例Before:● 常に200台以上のビルドマシンからなるフリート● Chat Ops (hubot)でデプロイ● およそ2日で完全に入れ替わる● しばらく古いコードと新しいコードが混在する問題
67CircleCIでの事例1年かけて以下を実施した● DockerとKubernetesの導入● マイクロサービス化
68CDのまとめ● CDが回るとフィードバックループも回る● CDに向いていない技術・組織はある● 既存システムに導入が無理なら新システムから
69Beyond CD
70CI/CD完全に理解した
71左CEOのJim, 右CTOのRob
72CDのその先1: 迅速なロールバック$ git revert CD 修正完了
73CDのその先2: 本番環境でのテスト
74テスト環境での失敗例１週間テスト環境でテスト
75テスト失敗例１週間テスト環境でテスト↓リリース (完璧だ!)
76テスト失敗例１週間テスト環境でテスト↓リリース (完璧だ!)↓本番環境のDockerのバージョンが古くてバグを踏む
77テスト失敗例Dockerのバージョンも同じにした！
78テスト失敗例Dockerのバージョンも同じにした！↓リリース (今度こそ完璧だ!)
79例 2Dockerのバージョンも同じにした！↓リリース (今度こそ完璧だ!)↓GitHubのAPI使用制限にひっかかる
80なぜこんなことが起こるか？テスト可能部分外部サービスビジネス要求仕様トラフィック・負荷テスト可能な部分はとても小さい！
81なぜこんなことが起こるか？テスト可能部分外部サービスビジネス要求仕様トラフィック・負荷テスト可能な部分はとても小さい！
82僕たちの重大な学びリリースしてみないと結局わからない！
83CDのその先3: 高度なリリース手法● カナリーリリース● ブルー グリーン デプロイ
84CDをつかいこなすと、、、● 迅速なロールバック● 本番環境でのテスト● 高度なリリース手法これらがもたらすものは、、、
85CDをつかいこなすと、、、● 迅速なロールバック● 本番環境でのテスト● 高度なリリース手法これらがもたらすものは、、、プログラミングに対する圧倒的な心理的安全
86Why CD?CI/CD Makes ProgrammingFUN!!
87CI/CDの未来
88CI/CDはどこへ向かうのか？CI
89CI/CDはどこへ向かうのか？CI CDelivery
90CI/CDはどこへ向かうのか？CI CDelivery CDeployment
91CI/CDはどこへ向かうのか？CI CDelivery CDeployment ????
92CI/CDはどこへ向かうのか？CI CDelivery CDeployment ????自動化自動化自動化CI/CDの歴史は自動化の歴史
93確実な自動化の未来今手動でやっていることを意識しなくてもいい時代● CIやCDの設定● モニタリング● デプロイ環境の構築
94CI/CDの未来$ git commit -m “First commit” && git push最初からクライマックス!!
Thank you.95
96デプロイとリリースの違いデプロイコードを本番環境に配置することリリース配置したコードでトラフィックをさばくこと
kimh
makenowjust
progate
syumai
treastrain
little_rubyist
ancaghenade
munetoshi
niftycorp
usamik26
hollycummins
ivargrimstad
ledsun
keavy
quramy
andyhume
frogandcode
trallard
tanoku
eileencodes
geeforr
trishagee
edds
akmur
lauravandoore