【レポート】DEV322：ソフトウェア開発チームにおける継続的インテグレーションのベストプラクティス

森永です。
最近DevOps系のサービスをガッツリ触るようになってその魅力に取りつかれております。 そんな中魅力的なタイトルがありましたので受講しました。

物凄い並びましたがなんとか入れました…

登壇者

Clare Liguori
Senior software engineer for the AWS Code services

セッション内容

Continuous Integration(CI)の紹介

• Continuous Integrationとは
  • 以下のループが基本
    • デベロッパー がコードを共有リポジトリに登録
    • 自動で実行して確認
    • 開発者がそのフィードバックを受取る
  • なぜCIが必要なのか？
    • バグの発見/修正が早くなる
    • デリバリが早く/頻繁になる
    • 開発者をブロックしない/時間を使える分成長する

CIのためのツール

• AWSが提供しているツール
  • コードの共有
    • CodeCommit
  • ビルド＆自動チェック
    • CodeBuild
  • 各機能をつなげる（Glue）
    • Amazon CloudWatch Events
    • AWS Lambda
• CodeBuildとは
  • フルマネージドビルドサービス
  • 自動スケールし、使った分だけ課金
  • 機能拡張性がある
  • ソースプロバイダーとして以下を使用可能
    • CodeCommit
    • S3
  • Build環境のスペックなども指定可能
  • ビルドに使用するイメージ
    • 予め用意されているイメージ
    • カスタムイメージを使用することも出来る
  • buildspec.yml
    • ビルドの詳細を記述
    • 依存関係のインストール、テストなども可能
  • Build結果は全体から詳細まで見れる
    • 全体の詳細（成功/失敗、全体にかかった時間）
    • フェーズ毎の詳細（各フェーズの成功/失敗、かかった時間）
    • ビルドのログ（各フェーズでのログ）
• 今後の展開
  • ソースにBitbucketを選択可能に
  • GitHubのPull Requestベースでビルド
  • CloudWatch Events経由で通知
  • Amazon Parameter Storeのsecretsパラメータを使用可能
  • AWS Configで設定の記録
• 今月のアップデート
  • VPC内のリソースと接続
  • Amazon S3内にライブラリをキャッシュ
  • リポジトリにバッジを表示

3つのテクニック

• CIの導入が楽だが効果は薄いものから、導入は難しいが効果抜群のものまで3つ紹介
• Nighty check（導入易、効果小）
  • 毎晩フルビルドとユニットテストを行い、現在のソースコードがビルドできるかチェック
  • 実装方法
    • CloudWatch Eventsのスケジュール実行でLambdaをキック
    • LambdaでCodeBuildを実行
  • 失敗した場合はビルドの詳細を見ることで原因が分かる
  • 更に効果を高めるには
    • ライブラリの自動アップデート
      • 古いライブラリを使い続けて幾星霜
      • 自動でアップデートしてテストまでする
      • 実装方法
        • CloudWatch Eventsのスケジュール実行でLambdaをキック
        • LambdaでCodeBuildを実行
        • CodeBuildでライブラリのアップデート
        • CodeCommitにcommit
    • メール通知
      • 毎晩のビルドが成功したか確認しに行くのはつらい
      • 失敗していたら通知する
      • 詳細もメールに記載すると楽
      • 実装方法
        • CodeBuildの状態をCloudWatch Eventsでチェック
        • LambdaでSESを呼び出しメール送信
  • サマリ
    • 実装
      • 毎日深夜にビルドを走らせる
    • フィードバックまでの時間
      • 16時間〜24時間後
    • チームへの影響
      • Broken codeはチームをブロックする
    • 効果を高めるには
      • ライブラリ自動アップデート、メール通知
• Branch Check（導入普、効果中）
  • pushされるたび常にフルビルドとユニットテストをする
  • 実装方法（CodeCommitの場合）
    • CodeCommitにPushされたことをCloudWatch Eventsで検知
    • CloudWatch EventsがLambdaをキック
    • LambdaでCodeBuildを実行
  • 更に効果を高めるには
    • Slack通知
      • ビルドに失敗したらSlackに通知する
      • 実装方法
        • CodeBuildの状態をCloudWatch Eventsでチェック
        • LambdaでSlackへ通知
    • バッジとして通知
      • CodeCommitやGitHubにバッジを設定して状態を確認できる
    • 依存関係のキャッシュ
      • 依存関係を毎回DLしていると時間がかかる
      • S3に依存関係をキャッシュしておくとDL時間が軽減できる
  • サマリ
    • 実装
      • ブランチへpushされる度にビルドする
    • フィードバックまでの時間
      • ビルドが終わったら即座に
    • チームへの影響
      • サイクルを早めることが出来るが、Broken codeはチームをブロックする
    • 効果を高めるには
      • Slack通知、バッジとして通知、依存関係のキャッシュ
• Pull request checks（導入難、効果大）
  • Pull requestのたび（レビューのたび）にフルビルドとユニットテストをする
  • 実装方法（CodeCommitの場合）
    • CodeCommitでPull requestが作成されたことをCloudWatch Eventsで検知
    • CloudWatch EventsがLambdaをキック
    • LambdaでCodeBuildを実行
  • 実装方法（GitHubの場合）
    • GitHubのWebHookでCodeBuildを実行
  • 更に効果を高めるには
    • 連携テスト
      • 実際に使用するリソースを使ってテスト（キャッシュなど）
      • VPC連携で簡単にできるようになった
    • 並列ビルド
      • たくさんのテストを一つのビルドで行うと遅い
      • 複数のビルドを並列に走らせて様々なテストを実行することで早くする
  • サマリ
    • 実装
      • プルリク（レビュー）の段階でコードをビルド、テストをする
    • フィードバックまでの時間
      • ビルドが終わったら即座に
    • チームへの影響
      • レビュー段階なのでBroken Codeがチームをブロックしない！
    • 効果を高めるには
      • 連携テスト、並列ビルド

最後に

CodeBuildやCodeCommitは最近アップデートが多い印象です。
かゆいところに手が届くようになってきているため、リリース当初触って諦めた方も再度お試しください。

並列ビルドの考え方は目からウロコでした。セッションでてよかった。