(Japanese) From Continuous Integration to DevOps - Japan Innovate 2013

【 A-4 】

継続的インテグレーションから
DevOps へ
アジャイルと自動化の進化

Sanjeev Sharma
IBM Worldwide Lead – DevOps Technical Sales
Executive IT Specialist, IBM Software Group
sanjeev.sharma@us.ibm.com
@sd_architect
http://bit.ly/sdarchitect

© 2013 IBM Corporation

アジャイル・ソフトウェア開発のマニフェス
ト
我々は、ソフトウェア開発を自ら行い、また、開発を行う者を支援することにより
、
常にソフトウェア開発の改善を模索しています。
その際に我々が重視するのは以下の項目です。
プロセスやツールより人やコミュニケーション
包括的な文書より実用的なソフトウェア
契約交渉より顧客との連携
計画の実行より変化への対応
前者も重要ですが、我々は、後者の項目をより重視します。
2


継続的インテグレーション (CI)
コンポ－ネン
ト・チームビ
ルド

インテグレー
ション・ビルド

コンポ－ネン
ト・チームビ
ルド

「継続的インテグレーションは、チームメンバーがそれぞれの作業を次々と結合し
て
いくというソフトウェア開発のプラクティスです。各メンバーの作業は少なくとも
1 日 1 回は結合されるので、 1 日当たり複数のインテグレーションがもたらされま
す。できるだけ迅速にインテグレーション・エラーが検出されるように、各インテ
グレーションは、自動化されたビルド（テストを含む）によって検証されます。」
- Martin Fowler
3


歴史的観点

4


CI の目的は迅速に問題を発見することであ
る
プラクティス：手動の継続的インテグレーション
– 自分の作業をチームに頻繁に結合するプラクティス
– 少なくとも 1 日 1 回コミットする

ツール：自動化された継続的インテグレーション
– コミット時に自動的にテストする（ビルドを含む）
– 自動的にチームにフィードバックされる

5


CI は生産性と品質を向上する
• プログラマー当たりの開発 LOC （コード行数）が 90%
上昇
少なくとも 1 日 1 回のビルドの実行時に

• 欠陥率が 36% 低下

各コードのチェックインでのインテグレーション / 回帰試験時に

「 Trade-offs between Productivity and Quality in Selecting Software Development Practices 」、 IEEE Software 、 2003 年 9
月 -10 月

6


2001 年 : 最初の “ CI” ツール

Cruisecontrol
Anthill User Manual
BUILDFORGE
7


2001 ～ 2004 年のアジャイルおよび CI
継続的インテグレー
アジャイル
（エクストリーム・プログション
ラミング )

•
•
•
•

8

小規模なチーム
開発者中心
高い規律
共同設置

• ビルドに焦点をあて
る
• 開発者試験
• オープンソース
• Lava Lumps

2005 ～ 2010 年 : エンタープライズへ！

9


エンタープライズ・アジャイル… ガバナン
ス?
「…顧客は私に、 3 か国にいる 400 人の開発者とともに、 500 万ドルのプ
ロジェクトでスクラムを使用するという計画を話しました…
「我々の足元をすくうのは、開発プラクティスではありません。継続的
インテグレーション、テスト・ファースト、リファクタリング、これら
はすべて理解されています。問題はガバナンスなのです」
大手調査会社のアナリストのコメント

10


テストと運用にかかるアジャイルと CI のプレッ
シャー
• ビジネス価値のあるソフトウェアの、更なるリリース頻度
のスピード向上が求められています。
• CI により、より多くのビルドがテストに利用できるように
なります。
• 新たな疑問 :

11

– 受け入れ難いリスクなしに、より迅速にテストし、より迅速にリ
リースするにはどうするか ?
– 18 か月サイクルの開発時に機能していたリリース・プロセスが、 1
か月

2006 ～ 2011 年のアジャイルおよび継続的デリバ
リー
アジャイル（スクラム）
• 小、中、大規模チーム
• 部門横断的
• 標準化
• 分散型

12

• セルフサービス
• ビルド、テストおよび
デプロイ
• エンタープライズ・ロー
ル
アウト
• 共有化されたインフラ
ストラクチャー


アジャイルはアプリ開発に勝利した

13


ソフトウェア・デリバリーの加速への挑戦

顧客

41

%

開発の遅延

14

事業部門

34

開発 / テスト

%

45

%

デプロイの遅延

本番への遅延


運用 / 本番

4～ 6

週間

コードを変更し、
リリースするまで

「実用的なソフトウェア」を重視するということ
は、
本番において実用的だということである

15


DevOps: アジャイルが運用まで広がった

なるほ
ど！

ビジネス・プロ
セス

ビジネス

チーン！

運用

開発

アジャイル開発
これを修正する

DevOps

これを修正す
る

*image from Dev2Ops.org
16


DevOps とは…
• アジャイル & リーンが、開発者だけでなく、
ソフトウェア・デリバリー・チェーン全体に適用
– ビジネス・開発・品質・セキュリティー・リリース・運用

• 効率性と一貫性によって推進
• ソフトウェアのデリバリーをエンド・ツー・エンドで最適
化
17


DevOps は破壊的である
Dev （開発）

Ops （運用）

•

非常に速いテンポ

 テンポが遅い

•

データベース / アプリケー
ションを最初から再構築でき
る

 データベースとアプリケー
ションに対して増分更新さ
れる

–

•

18

–

監査はなくても支障がない
–

•

ロールバックの必要がない

ロールバックが膨大である

 監査が重要

セキュリティー、追跡可能性、
職務の分離

–

新しい環境が一般的である

セキュリティー、追跡可能性、職務
の分離

 新しい環境は珍しい


デミングサイクル
•
•
•

ウイリアム・デミング－アメリカの統計学者
日本の製造業や商取引に大きな影響を与えた
PDCA （計画、実行、評価、改善）サイクル
（デミングサイクル）で有名
–

•

19

私は「改善（ Act ）」より
「調整（ Adjust ）」と言う方が好きだ

DevOps には PDCA サイクルがある


品質

DevOps アプローチ : 顧客との連続的なフィードバック・ループを生成す
るために、　ソフトウェアのイノベーションとデリバリーにリーン原則を
適用する
1

1. アイデアを本番にすばやく
反映させる
2. 人々がそれを使用できるようにする
3. フィードバックを得る

2

事業部門
3

顧客

オーバーヘッドと再
修正
価値のある作業

20

DevOps アプローチを採用して、継続的
に変更を管理し、フィードバックを
入手し、
ユーザーに変更を知らせる

顧客が求めているこ
とを知るのに必要で
ない活動は取り除く

DevOps

市場機会を捉える時間と顧客のフィードバックを得る時間を短縮することを
可能とするための、継続的なソフトウェア・デリバリーを実現する企業規模の能力
DevOps ライフサイクル
顧客

事業部門

開発 / テスト

運用 / 本番

継続的なイノベーション、フィードバック、改善

ソフトウェア・デリバリーの加速
スピード、コスト、品質、およびリスクのバランス
顧客からフィードバックを得るまでの時間の短縮
21


ツールの共有は難しい

• 従来の硬直的な事業組織は、エンド・ツー・エンドのイ
ンフラストラクチャーを制限してしまう可能性がある
– 開発中心のツールは、データセンターでの使用に適さないこと
がある
– 運用中心のツールは、開発のためにデプロイされることが稀で
ある

22


本番では、「 1 つのビルド」だけをデプロイし
ていない
典型的な本番デプロイの取組みの範囲は？

単一のコンポ－ネント、サービス、ティアのデプロイ
フルアプリケーションのデプロイ
（いくつかのコンポーネントの可能性）
システムのデプロイ（いくつかのアプリケーションを
含む）
無関係のものも含む場合がある、
複数のアプリケーションまたはシステムのデプロイ

1 回に 1 つのビルドを
デプロイするのは
12 ％しかない

23


ニーズ : 本番に適したパイプライン・モデル

24


ニーズ : 本番に適したパイプライン・モデル

25


統合されたパイプラインとスナップショットとの併
用

Web

Snapshot

Mid. Code

3
2

Mid. Config
DB

26

3

1


2

今日のアジャイルおよび自動化
アジャイル
（ Scrumban + DevOps ）
•
•
•
•
•

27

小規模および大規模チーム
ビジネスから運用まで
標準化
分散型
複数のビルドを本番に

自動化
（プロビジョン → 監視）
•
•

•
•

Platform as a Service
プロビジョン、ビルド、テス
ト、
デプロイ、監視
エンタープライズ
共有化されたインフラストラ
クチャー


「本番」を意識してマニフェストを読む
我々は、ソフトウェア開発を自ら行い、また、開発を行う者を支援することにより
、
常にソフトウェア開発の改善を模索しています。
その際に我々が重視するのは以下の項目です。
プロセスやツールより人やコミュニケーション
包括的な文書より実用的なソフトウェア
契約交渉より顧客との連携
計画の実行より変化への対応
前者も重要ですが、我々は、後者の項目をより重視します。
28


デリバリーパイプラインの能力：ツール
必要に応じて段階的に適用できます
Rational Focal Point
Rational Requirements Composer

IBM UrbanCode Release

SmartCloud Orchestrator
IBM PureApplication System

Chef

IBM UrbanCode Deploy

Line of
Business

Jenkins
Rational Build Forge

Rational Team Concert

Rational Quality Manager
Rational Test Workbench
Rational Test Virtualization Server

SmartCloud Application
Performance
Management
Tealeaf

29


関連展示のご案内
ただいまの講演に関連する展示は　　　となります。
01 04

14

第１会場第 2 会
場
基調講演会場第３会場

13
12

ソリューション・ツアー
受付

11

総合受付

10
09
08

Information Wall
07 06 05 04

DevOps
ゾーン
03 02 01


ものづくり
ゾーン

ワークショップ、セッション、および資料は、 IBM またはセッション発表者によって準備され、それぞれ独自の見解を反映したものです。それらは情報提供の目的のみで提供されて
おり、いかなる参加者に対しても法律的またはその他の指導や助言を意図したものではなく、またそのような結果を生むものでもありません。本講演資料に含まれている情報につい
ては、完全性と正確性を期するよう努力しましたが、「現状のまま」提供され、明示または暗示にかかわらずいかなる保証も伴わないものとします。本講演資料またはその他の資料
の使用によって、あるいはその他の関連によって、いかなる損害が生じた場合も、 IBM は責任を負わないものとします。本講演資料に含まれている内容は、 IBM またはそのサプラ
イヤーやライセンス交付者からいかなる保証または表明を引きだすことを意図したものでも、 IBM ソフトウェアの使用を規定する適用ライセンス契約の条項を変更することを意図し
たものでもなく、またそのような結果を生むものでもありません。
本講演資料で IBM 製品、プログラム、またはサービスに言及していても、 IBM が営業活動を行っているすべての国でそれらが使用可能であることを暗示するものではありません。
本講演資料で言及している製品リリース日付や製品機能は、市場機会またはその他の要因に基づいて IBM 独自の決定権をもっていつでも変更できるものとし、いかなる方法において
も将来の製品または機能が使用可能になると確約することを意図したものではありません。本講演資料に含まれている内容は、参加者が開始する活動によって特定の販売、売上高の
向上、またはその他の結果が生じると述べる、または暗示することを意図したものでも、またそのような結果を生むものでもありません。パフォーマンスは、管理された環境におい
て標準的な IBM ベンチマークを使用した測定と予測に基づいています。ユーザーが経験する実際のスループットやパフォーマンスは、ユーザーのジョブ・ストリームにおけるマルチ
プログラミングの量、入出力構成、ストレージ構成、および処理されるワークロードなどの考慮事項を含む、数多くの要因に応じて変化します。したがって、個々のユーザーがここ
で述べられているものと同様の結果を得られると確約するものではありません。
記述されているすべてのお客様事例は、それらのお客様がどのように IBM 製品を使用したか、またそれらのお客様が達成した結果の実例として示されたものです。実際の環境コスト
およびパフォーマンス特性は、お客様ごとに異なる場合があります。
IBM 、 IBM ロゴ、 ibm.com 、 Focal Point 、 PureApplication 、 Rational 、 Rational Team Concert 、および Smarter Planet アイコンは、世界の多くの国で登録された International Business Machines
Corporation の商標です。
他の製品名およびサービス名等は、それぞれ IBM または各社の商標である場合があります。
現時点での IBM の商標リストについては、 www.ibm.com/legal/copytrade.shtml をご覧ください。

33


(Japanese) From Continuous Integration to DevOps - Japan Innovate 2013

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (15)

Andere mochten auch

Andere mochten auch (9)

Ähnlich wie (Japanese) From Continuous Integration to DevOps - Japan Innovate 2013

Ähnlich wie (Japanese) From Continuous Integration to DevOps - Japan Innovate 2013 (20)

Mehr von Sanjeev Sharma

Mehr von Sanjeev Sharma (20)

(Japanese) From Continuous Integration to DevOps - Japan Innovate 2013

Hinweis der Redaktion