継続的インテグレーション入門

book todo

todo：1部についてもまとめる。

 

遅ればせながら掲題の書籍読みました。

本書は2部構成になっています。

1部ではContinuous Integration(以下CI)の全体像や背景が記されています。

2部では継続的(自動的)に行うべき5つのプラクティスについて記されています。

最後に具体的なCIツールについて記載されています。P243～P285なので分量多めです。

 

本書の中ではCIサーバーに設定するビルドスクリプトも記載されているのでCIサーバー構築時には参考になると思います。

まだ、構築に至っていないので確証ありませんが。

 

2部で紹介されていた5つのプラクティスは次のとおりです。

  • 継続的データベースインテグレーション
  • 継続的テスト
  • 継続的インスペクション
  • 継続的デプロイ
  • 継続的フィードバック

それぞれに付いて簡単にまとめておこうと思います。

 

◆継続的データベースインテグレーション

  • データベースの構築（テストデータ投入・ジョブ・ストアド含む）も自動化すべき。
  • DBAが開発チームと別になりがちなので一緒にすべき。
  • 開発チームにDBの変更権限を与えよう。そうすればDBAは本来の仕事に集中できる。
  • DBAの本来の仕事は、パフォーマンスチューニングやデータの正規化など。
  • ローカル開発環境にデータベースサンドボックスを使う。

◆継続的テスト

  • テストは次の4つに分類できる。
  • 単体テスト/結合テスト/システムテスト/機能(受入)テストの4つ。本書の定義は次の通り。
  • 単体テスト：ソフトウェアの小さな単位(多くの場合1つのクラスの振る舞い)を検証する。データベースなど外部との連携がない。
  • 結合テスト：複数のコンポーネントが相互に連携し、期待した振る舞いをしているか検証する。多くの場合、データベースを必要とする。
  • システムテスト：ユーザー向けのGUIやWebサービスなどの外部I/Fからシステム全体が設計どおりに機能することを検証する。
  • 機能テスト：ユーザーの観点からアプリケーションの機能性を検証する。
  • （感想）それぞれどういうテストがどれに分類するかっていうのはプロジェクトによって違うと思うからプロジェクト内で決める必要があるかなって思った。
  • 処理が軽い(FBが早い)テスト(単体テスト、一部の結合テスト)はコミット毎に実行すればいいが(1次ビルド)、処理が重たい(FBが遅い)テストは日次や特定のコミットごとなど(2次ビルド)実行頻度を減らしたほうが良い。
  • FBバックが遅いとCIの価値がなくなってしまう。

◆継続的インスペクション

  • コードの複雑度、コード規約の順守度を検知する仕組み。
  • 実行に時間がかかるので日次など(2次ビルド)実行頻度は多くないほうが良い。

◆継続的デプロイ

  • リポジトリラベルを付ける。関連するファイル群にラベルを付ける。
  • ビルドラベルを付ける。ビルドされたバイナリを識別するラベルを付ける。
  • 既存の環境を削除(クリーンに)してからデプロイする。
  • すべてのテストを実行しすべてが成功したらデプロイする。

◆継続的フィードバック

  • フィードバックは次の4点について気をつける。
  • 適切な相手：だれに送るべきか。
  • 適切なタイミング：問題発生時に送るべきか。日次でいいか。週次でいいか。
  • 適切な方法：メールがいいか。ランプがいいか。twitterがいいか。
  • 適切な情報：どんな情報を必要としているか。
  • メールやSMS、ランプなどフィードバック方法はいろいろある。
  • メールばかりに頼ってしまうと、メール過多になり読まなくなってしまう。

継続的インテグレーション入門 開発プロセスを自動化する47の作法