継続的インテグレーションから継続的デプロイへ
Jenkinsコミッタの川口さんの記事を見かけたのでリンクしておく。
【元ネタ】
InfoQ: 継続的デリバリのパターン
InfoQ: Jenkinsによる継続的インテグレーションのススメ(1)
InfoQ: Jenkinsによる継続的インテグレーションのススメ(2) ~Jenkinsを使い始める~
InfoQ: Jenkinsによる継続的インテグレーションのススメ(3) ~Jenkinsで分散ビルド~
(引用開始)
元々CIはこのようにビルド・テストの実行といった狭い分野にフォーカスしていましたが、最近では、汎用の自動化プラットフォームとして、バックアップ・リリース・デプロイメントなどのスクリプト可能な作業をなんでもやらせる事も広義のCIに含んでよいと思います(Continuous Deploymentなどと呼ばれる事もあります)。今までは、こうした作業は担当者が個人の計算機上でスクリプトとして記述することが普通でしたが、ちょうど開発者がIDEとは切り離された誰にでも実行可能なビルドスクリプトの利便性に気づいたように、担当者の個人の環境を離れて誰にでも見え、修正でき、実行できるような形に書く事で、属人性と環境依存性を排除することができます。
(引用終了)
CIというアイデアは、単なるビルド管理の自動化だけではない。
「継続的インテグレーション入門」に書かれているように、継続的デプロイ・継続的インスペクション・継続的フィードバックなどあらゆる作業の自動化をサポートできる。
PaaSなどのクラウドでサーバーやハードウェアと言うインフラ管理も自動化できるので、それらと組み合わせれば、本番環境構築、本番リリース作業やデータ移行などをもっと自動化出来るはず。
それによって、顧客へより早く正確に納品できるようになるはず。
Continuous Delivery~TDDとCIの次に現れた自動化の概念: プログラマの思索
更なるCIツールの使い道は、バッチ処理のサポートだろうと思う。
ソフトウェア工学におけるメトリクス収集処理は、CIツールを使うことでより簡単に、より利便性が良くなると思う。
Jenkinsの特長 - メトリクス収集サーバの視点から -: ソフトウェアさかば
Redmineを業務システム化するアイデア~メトリクス集計の本質は集計バッチ処理: プログラマの思索
| 固定リンク
「ソフトウェア工学」カテゴリの記事
- 「ソフトウェアアーキテクチャ・ハードパーツ」の情報リンク~マイクロサービスの設計技法の課題は何なのか(2023.11.12)
- パッケージ原則とクラス原則の違いは何なのか(2023.10.14)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- QAエンジニアの役割は開発チームのガードレールみたいなものという考え方(2023.08.21)
- テストアーキテクチャ設計モデルとJSTQB概念モデルの比較(2023.07.02)
「構成管理・Git」カテゴリの記事
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
「Agile」カテゴリの記事
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 日本のアジャイル開発の先人による話が良かった(2023.07.15)
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
コメント