継続的デリバリーの概観

1.はじめに

継続的デリバリーで、ソフトウェアデリバリーの問題を解決するための導入です。
継続的デリバリーが、ソフトウェアデリバリーの問題をどのように解決するかについて、概観を記載します。
『継続的デリバリー信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』の第1章に対応します。

2.概要

デプロイメントパイプラインを構築し以下の要件を満たすことが、ソフトウェアデリバリーの問題を解決するための、核となる考え方である。

プロセスの可視化
高速フィードバック
任意のバージョンを任意の環境に完全に自動化されたプロセスでデプロイ

3.目的

継続的デリバリーの目的は、以下の2点である。

サイクルタイムの短縮
品質の向上

また、これらの目的を満たす主な方法は、以下の通りとなる。

自動化によるリリースプロセスの制御
短期間のリリースによる高速フィードバック

4.問題・対応概要

(1)リリースアンチパターン

リリースアンチパターンとして、以下の3つが挙げられる。あわせて、対応も記載する。

手動デプロイ
対応：デプロイメントスクリプトの使用。あらゆる環境に対して同じスクリプトを使用する。
開発とデプロイの乖離
対応：デプロイプロセスを開発プロセスに統合する。
手動の構成管理
対応：仮想化などを利用した構成管理の自動化。

(2)リーンの哲学に基づいた対応

継続的デリバリーは、リーンの哲学の影響を受けており、スケールするプロセスとなる。

(3)継続的デリバリーによる解決

継続的デリバリーの原則は、ソフトウェアリリースのための、反復可能かつ信頼可能なプロセスを構築することである。
ほぼ全ての自動化と、ビルド・デプロイ・テスト・リリースに必要な全てをバージョン管理するという原則によって、継続的デリバリーを実現する。

(4)「品質を作りこむ」

デミングの言う「品質を作りこむ」を実践するために、以下の2つの原則がある。

こまめな統合と継続的改善
あるいは、早期検出と早期対応

(5)デリバリープロセス

デリバリープロセスに対する責任は、ソフトウェアプロセスにかかわる全ての人が負う。
まず、デリバリープロセスの改善は、以下の点を一目で見ることができるシステムの構築から始める。

アプリケーションが正常かどうか
様々なビルドの状態
どのテストに通過したか
デプロイ可能な環境の状態

5.対応詳細

(1)変更のフィードバック

あらゆる変更に対して、フィードバックプロセスを引き起こす必要がある。

a.フィードバックプロセスを引き起こすべき変更

コード
CIが、コードの変更についてフィードバックする。
設定
構成管理が、設定の変更についてフィードバックする。
環境
基盤や環境の管理が、環境の変更についてフィードバックする。
データ
データ管理が、データの変更についてフィードバックする。

b.素早くフィードバックを得るための、ソフトウェア開発プロセス上の注意

バージョン管理システムに対して、こまめにコミットする。
コードを別々のコンポーネントに分割する。

(2)リリース水準

アプリケーションの品質がリリース水準を満たすように、あらゆる変更を以下の方法で検証する。

包括的な自動テストと併せて、ビルド、デプロイメントを自動化する。
できるだけ、チェックイン前にバグを検出する。

(3)継続的インテグレーション（CI）

CIとは、こまめな統合を論理的に極限まで突き詰めたプラクティスである。
変更がシステムに取り込まれた時点で検出し、問題があれば検出時点で修正する。
CIにより、ソフトウェアが常に動く状態となる。
また、テストが十分に網羅的で、本番とほぼ同等の環境でテストを実行しているとき、ソフトウェアは常にリリースできる状態となる。

(4)ソフトウェアデプロイメント

ソフトウェアデプロイメントは、以下の3要素で構成する。

アプリケーションの実行環境のプロビジョニングと管理
適切なバージョンのアプリケーションのインストール
必要なデータや状態を含む、アプリケーションの設定

(5)バージョン管理の原則

変更セットが単一の識別子を持つ。

(6)自動化

自動化の対象は以下の通り。

ビルド
デプロイ
テスト
リリース

以下は自動化が可能な例。

DBのアップグレードやダウングレード
ネットワークやファイアウォールの定義

自動化は、ビルド・デプロイ・テスト・リリースのプロセスの中で、ボトルネックとなっているところから始める。

(7)機能の完了条件

現実的な観点から、以下を機能の完了条件とする。

機能をショーケースにかける。
疑似本番環境にリリースし、ユーザコミュニティの代表者に対してデモを行う。

6.影響・作用

以上の対応を実践することで、以下のような恩恵を得ることができる。

反復可能で、信頼でき、予測可能なリリースプロセスを構築できる。
プルシステムであるというデプロイメントパイプラインの原則により、チームが権限を獲得する。
変化するものを積極的にバージョン管理することで、エラーを削減できる。
例：コードを実行する環境を定義する設定情報をバージョン管理することで、設定によるエラーを回避できる。
アプリケーションを新環境で動かし始めるためのタスクをシンプルにすることで、デプロイメントが柔軟になり、コストも削減できる。

7.おわりに

以上が、継続的デリバリーによる、ソフトウェアデリバリーの問題の解決のための、導入・概観です。

8.参考文献

『継続的デリバリー信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』第1章　ソフトウェアデリバリーの問題

Learning Records

『継続的デリバリー』第1章学習メモ