継続的デリバリーのパイプライン

継続的インテグレーションの 次の段階にあたるのが、 継続的デリバリーのパイプラインです。 継続的デリバリーの意味や、 正しい実践のための ５つの鉄則を紹介します。 継続的デリバリーとは、 変更のたびに本番と同等の環境に デプロイし、結合テストと受け入れテストを 自動で行うことです。 ジェズ・ハンブルと デービッド・ファーリーの 『継続的デリバリー』は、 必読の１冊です。 前のレッスンで、 ビルドのたびにアーティファクトが できると言いましたね。 ステージング、テスト、 本番用にリビルドしないことです。 ビルドは１回限りとし、 全環境に統一としないと、 各テストの有効性が証明できません。 アーティファクトには、 いかなる変更も禁止しましょう。 権限設定で変更を不可にして 保存します。 私が構築したパイプラインでは、 CI（シーアイ）システムは アーティファクトをリポジトリに書くだけ、 デプロイシステムは読むだけ、 と権限を絞りました。 アーティファクトのリビルドや 変更をすべきでない理由は２つあります。 まず、バグ対処での信頼関係です。 開発、運用、品質保証が、ステージ間で 違いがないと信頼できることは重要です。 アーティファクトの違いは、 チェックサムでわかります。 次の理由は、可監査性です。 継続的デリバリーでは、 ビルドアーティファクトから 動作システムまでコードバージョンが 追跡できます。 しかし、リビルドや変更をすると、 可監査性が保てなくなります。 ここで、アーティファクトが システム上で辿る流れを見ておきましょう。 コードがバージョン管理システムに 記録されると、それがトリガーになって CI システムのビルドが起動します。 ビルドが完了すると、生成された アーティファクトが中央リポジトリに 反映されます。 次は、アーティファクトを ライブ環境にデプロイする ワークフローです。 ここはほぼ本番環境のコピーで、 呼び方は CI 環境、ステージング環境、 テスト環境、プレ本番環境など さまざまです。 ここで、スモークテスト、結合テスト、 受け入れテストが実施されます。 テストは極力自動化しましょう。 テストをすべてパスすると、 アーティファクトがリリースされます。 そして、必要なタイミングで 本番環境にデプロイされます。 プレ本番環境は、…