結局CI/CDをすると何が嬉しいのか？

Transcript

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