CIとソフトウェアのデリバリーについて
ビルド、デプロイ、テスト、リリースのタスクの重要性
ソフトウェアのビルド、デプロイ、テスト、リリースはアドホックにマニュアルで行われることが多いが、実際にはこれらのタスクは極めて重要であり、設計や実装と同じく、顧客に価値を提供する「value stream」の一部である。そのため、これらのタスクは効率化、形式化されるべきである。value streamのイメージ
また、マニュアルによる操作は、以下のような問題がある。
- いざ不具合があったときの対応が難しい
- ミスが起きやすく、時間がかかる
- これらのタスクに時間がかかると、テスト結果や顧客からのフィードバックを得るのに時間がかかる
- ビルド、デプロイ、テスト、リリースが大変だとその作業が先にばしにされてしまい、ますます自体を悪化させる
- タスクを繰り返し可能とする
- ミスを減らす
- 予想可能なタスクにする
- 一回のジャンプを小さくすることで、修正にかかるコストを減らす
- フィードバックを得るのにかかる時間を短縮する
- プロジェクトに関わるメンバ全員が、ソフトウェアのデリバリーに責任を持つ
- プロジェクトに関わるメンバでデリバリープロセスを改善してく
- ソフトウェアの設定、環境の設定はソースコードと同じようにVCSで管理されるべき
- ソフトウェア、環境の設定はソースコードと同様に一文字の違いでソフトウェアを破壊することが可能であるため、ソースコードと同様にVCSで管理し、テストしなければならない。
- 環境の設定は自動化されるべき
- 特に環境の設定は適当になりやすいが、非常に重要であるため、Puppetなどのツールを用いてVCSと同期すべき
- ライブラリの依存関係の管理
- ライブラリの依存関係は極めて重要なので、Maven, Ivy, Gradleなどのツールで自動化し、VCSで管理すべき
- あらゆるものをVCSで管理する
- ソースコード、設定、環境設定、開発環境、ドキュメントなど、開発に関わるものは何でも突っ込め!
- ビルド、テストを自動化する
- テスターは、探索的テスト、ユーザビリティのテストなどより付加価値の高い自動化できない試験を頑張ってもらう
- チーム内での合意を得る
- CIはツールではなくてプラクティスなので、チーム内での合意が得られなければ機能しない
- 小刻みにチェックインする
- 一回のチェックインの修正規模が大きいと修正が大変なので小刻みにチェックインする
- 自動化されたテストスイーツを用意する
- チェックインされた成果物が既存の成果物を壊していないかを確認する
- ビルド、テストが壊れたまま放置しない
- チェックインでビルド、テストが壊れたら、原因を調査し、治すことを最優先する
- CI Server
- Jenkins(他にもいっぱいあるっぽい)
- コードの品質チェック
- Checkstyle, FindBugs
- Build Script
- ANT, Maven, Gradle
- xUnit Test
- JUnit, NUnit
ソフトウェアのデリバリーの原則
ビルド、デプロイ、テスト、リリースなど、あらゆるタスクを自動化する設定の管理
CI(Continuous Integration)
ソフトウェアの品質を高く保つためのExtreme Programmingのプラクティス。VCSに小刻みに成果物をコミットし、そのタイミングで一連の自動化されたビルド、テストを走らせることで、ソフトウェアの不具合を早期に洗い出し、修正することを可能とする。 前提条件Deployment Pipeline
CIでは、ソースコードなどを弄る開発作業を対象としているが、CIの考え方を受け入れ試験、リリースなどのソフトウェアのコンセプト立案から顧客に価値を届けるまでのデリバリープロセス全体に拡大し、一連の流れを「Deployment Pipeline」としてモデル化する。「Deployment Pipeline」は、単一の流れに沿った開発からのパラダイムシフトであり、CPUのパイプライン処理のごとく、五月雨的にVCSへのチェックインを契機としてビルド、自動化されたテストを実行し、そのままテストチームでのマニュアルテストを実施し、ソフトウェアを「常に」リリース可能な状態にすることを可能とする。「Deployment Pipeline」をどのように実装するのかは、プロジェクトの要件ごとに大きくことなるので、プロジェクトごとに「Deployment Pipeline」を設計、実装し、改善していくことが必要となる。 こんな感じの流れがCPUのパイプライン実行の如く、五月雨的に動くことになります。
また、「Deployment Pipeline」では、「ビルド、デプロイ、テストなどをボタンひとつで実現できるように徹底的に自動化する」という、CIの考え方が基盤にあるので、特に何かを契機にすることなく、動くソフトウェアをいつでも、だれでもデプロイすることができ、テスターやユーザーが指示を待たなくても自発的にテストを実施できる、また、動くソフトウェアが常にデプロイ可能な状態なので、ソフトウェアのデリバリー作業を「見える化」し、開発関係者に安心感を与える効果もある。
