継続的インテグレーションから継続的デプロイへ

Jenkinsコミッタの川口さんの記事を見かけたのでリンクしておく。

【元ネタ】
InfoQ: 継続的デリバリのパターン

InfoQ: Jenkinsによる継続的インテグレーションのススメ(1)

InfoQ: Jenkinsによる継続的インテグレーションのススメ(2) ~Jenkinsを使い始める~

InfoQ: Jenkinsによる継続的インテグレーションのススメ(3) ~Jenkinsで分散ビルド~

(引用開始)
元々CIはこのようにビルド・テストの実行といった狭い分野にフォーカスしていましたが、最近では、汎用の自動化プラットフォームとして、バックアップ・リリース・デプロイメントなどのスクリプト可能な作業をなんでもやらせる事も広義のCIに含んでよいと思います（Continuous Deploymentなどと呼ばれる事もあります）。今までは、こうした作業は担当者が個人の計算機上でスクリプトとして記述することが普通でしたが、ちょうど開発者がIDEとは切り離された誰にでも実行可能なビルドスクリプトの利便性に気づいたように、担当者の個人の環境を離れて誰にでも見え、修正でき、実行できるような形に書く事で、属人性と環境依存性を排除することができます。
(引用終了)

CIというアイデアは、単なるビルド管理の自動化だけではない。
「継続的インテグレーション入門」に書かれているように、継続的デプロイ・継続的インスペクション・継続的フィードバックなどあらゆる作業の自動化をサポートできる。
PaaSなどのクラウドでサーバーやハードウェアと言うインフラ管理も自動化できるので、それらと組み合わせれば、本番環境構築、本番リリース作業やデータ移行などをもっと自動化出来るはず。
それによって、顧客へより早く正確に納品できるようになるはず。

継続的インテグレーションを再考: プログラマの思索

Continuous Delivery～TDDとCIの次に現れた自動化の概念: プログラマの思索

クラウドの本質はインフラ管理のIT化: プログラマの思索

更なるCIツールの使い道は、バッチ処理のサポートだろうと思う。
ソフトウェア工学におけるメトリクス収集処理は、CIツールを使うことでより簡単に、より利便性が良くなると思う。

Jenkinsの特長 - メトリクス収集サーバの視点から -: ソフトウェアさかば

Redmineを業務システム化するアイデア～メトリクス集計の本質は集計バッチ処理: プログラマの思索