1で自己紹介- Kim- 元CircleCIで開発者- 現CircleCI Japan
View Slide
2結局 すると何が嬉しいの?
3バグを書いてもえらい人に怒られなくなる
4どうゆうこと?
5よくある開発フロー開発↓レビュー↓テスト↓リリース
6テストできる範囲には制限がある
7例1週間ステージング環境でテスト
8例1週間ステージング環境でテスト↓リリース (完璧や!)
9例1週間ステージング環境でテスト↓リリース (完璧や!)↓本番環境のDockerが古くてバグを踏む
10例2 週間ステージング環境でテスト
11例2 週間ステージング環境でテスト↓リリース (今度こそ完璧や!)
12例2 週間ステージング環境でテスト↓リリース (今度こそ完璧や!)↓GitHubのAPI RateLimitにひっかかる
13例メール送信前にしっかりチェックしたのに送った瞬間に間違いを見つける
14結局、リリースしないとわからない
15じゃー、どうするか?
16本番環境でテスト!
17の開発フロー開発↓レビュー↓テスト↓CI/CDで自動リリース注:半分釣り
18の開発フロー 続きやべぇ, ロールバック↓Revert PR↓CI/CDで自動リリース↓ロールバック完了
19つまり、 があるおかげで簡単にロールバックできる
20この開発フローのメリット
211. バグを作ってもすぐに戻せる心理的安全
222. リリースサイクルの短縮
233. いつでも戻せるコードを書く習慣がつく (後方互換を常に意識)
24リリース中心の文化が根付くと他にも色々できるようになる
25フィーチャーフラグ
26ローリングアップデート
27リリースサイクルさらに
28まとめ
29CI/CDがあればバグ、恐れるに足らず
30より早く、自由に、プロダクトを開発
31追記:
32テストしないことや見切り発車を推奨しているのではない
33できる限りのテストをすることは開発者(プロ)の責任
34CircleCIでももちろんできるテストは開発環境でやっています
35CircleCIはテストしないんだって!っとかTweetしないでね
36宣伝 会社- Twitter @CircleCIJapan- Qiitaアドベントカレンダーhttps://qiita.com/advent-calendar/2018/circleci- ミニハッカソンやりますhttps://circleci.connpass.com/event/109136/
37宣伝 個人日本初の電動キックボードのサービスを作ろうとしています
38