• Save
(Japanese) From Continuous Integration to DevOps - Japan Innovate 2013
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 1,087 views

Presentation on the history of evolution of DevOps from CI. Delivered at Innovate Japan 2013. Japanese Version. Hat tip to Eric Minick, who presented an earlier version at Innovate 2013 in Orlando, ...

Presentation on the history of evolution of DevOps from CI. Delivered at Innovate Japan 2013. Japanese Version. Hat tip to Eric Minick, who presented an earlier version at Innovate 2013 in Orlando, FL.

English ver available here: http://www.slideshare.net/sanjeev-sharma/final-continuous-integration-todevops-japan-innovate-v11

Statistics

Views

Total Views
1,087
Slideshare-icon Views on SlideShare
1,081
Embed Views
6

Actions

Likes
0
Downloads
0
Comments
0

3 Embeds 6

http://www.linkedin.com 3
https://twitter.com 2
http://s.deeeki.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Speaker: Jeff <br />
  • Scrum – Project Management to Scrum Masters <br /> CI – Build management. Used to have build guys. Now we have build tooling guys. <br /> There are bumps! <br />
  • Scrum – Project Management to Scrum Masters <br /> CI – Build management. Used to have build guys. Now we have build tooling guys. <br /> There are bumps! <br />
  • From the Agenda: <br /> In this “new normal,” the most forward thinking companies will: Establish an enterprise capability for accelerated delivery of software that enables them to seize market opportunities and reduce time to customer feedback, improve governance while balancing quality and cost <br />
  • Optional slide. Graphic is available in English only. <br />
  • Mandatory closing slide (2 of 2) <br /> Thank You Slide (available in English only). <br />
  • Mandatory closing slide (1 of 2) <br /> Acknowledgements and disclaimers <br /> IBMers must include This mandatory “Acknowledgements and Disclaimers” slide at the end of your presentation before the closing “Thank You” slide. <br /> - You will need to customize the “Acknowledgements and Disclaimers” text in red appropriately. <br />

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

  • 【 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 © 2013 IBM Corporation
  • 継続的インテグレーション (CI) コンポ-ネン ト・チームビ ルド インテグレー ション・ビルド コンポ-ネン ト・チームビ ルド 「継続的インテグレーションは、チームメンバーがそれぞれの作業を次々と結合し て いくというソフトウェア開発のプラクティスです。各メンバーの作業は少なくとも 1 日 1 回は結合されるので、 1 日当たり複数のインテグレーションがもたらされま す。できるだけ迅速にインテグレーション・エラーが検出されるように、各インテ グレーションは、自動化されたビルド(テストを含む)によって検証されます。」 - Martin Fowler 3 © 2013 IBM Corporation
  • 歴史的観点 4 © 2013 IBM Corporation
  • CI の目的は迅速に問題を発見することであ る プラクティス: 手動の継続的インテグレーション – 自分の作業をチームに頻繁に結合するプラクティス – 少なくとも 1 日 1 回コミットする ツール : 自動化された継続的インテグレーション – コミット時に自動的にテストする(ビルドを含む) – 自動的にチームにフィードバックされる 5 © 2013 IBM Corporation
  • CI は生産性と品質を向上する • プログラマー当たりの開発 LOC (コード行数)が 90% 上昇 少なくとも 1 日 1 回のビルドの実行時に • 欠陥率が 36% 低下 各コードのチェックインでのインテグレーション / 回帰試験時に 「 Trade-offs between Productivity and Quality in Selecting Software Development Practices 」、 IEEE Software 、 2003 年 9 月 -10 月 6 © 2013 IBM Corporation
  • 2001 年 : 最初の “ CI” ツール Cruisecontrol Anthill User Manual BUILDFORGE 7 © 2013 IBM Corporation
  • 2001 ~ 2004 年のアジャイルおよび CI 継続的インテグレー アジャイル (エクストリーム・プログ ション ラミング ) • • • • 8 小規模なチーム 開発者中心 高い規律 共同設置 • ビルドに焦点をあて る • 開発者試験 • オープンソース • Lava Lumps © 2013 IBM Corporation
  • 2005 ~ 2010 年 : エンタープライズへ! 9 © 2013 IBM Corporation
  • エンタープライズ・アジャイル… ガバナン ス? 「…顧客は私に、 3 か国にいる 400 人の開発者とともに、 500 万ドルのプ ロジェクトでスクラムを使用するという計画を話しました… 「我々の足元をすくうのは、開発プラクティスではありません。継続的 インテグレーション、テスト・ファースト、リファクタリング、これら はすべて理解されています。問題はガバナンスなのです 」 大手調査会社のアナリストのコメント 10 © 2013 IBM Corporation
  • テストと運用にかかるアジャイルと CI のプレッ シャー • ビジネス価値のあるソフトウェアの、更なるリリース頻度 のスピード向上が求められています。 • CI により、より多くのビルドがテストに利用できるように なります。 • 新たな疑問 : 11 – 受け入れ難いリスクなしに、より迅速にテストし、より迅速にリ リースするにはどうするか ? – 18 か月サイクルの開発時に機能していたリリース・プロセスが、 1 か月 © 2013 IBM Corporation
  • 2006 ~ 2011 年のアジャイルおよび継続的デリバ リー アジャイル(スクラム) • 小、中、大規模チーム • 部門横断的 • 標準化 • 分散型 12 • セルフサービス • ビルド、テストおよび デプロイ • エンタープライズ・ロー ル アウト • 共有化されたインフラ ストラクチャー © 2013 IBM Corporation
  • アジャイルはアプリ開発に勝利した 13 © 2013 IBM Corporation
  • ソフトウェア・デリバリーの加速への挑戦 顧客 41 % 開発の遅延 14 事業部門 34 開発 / テスト % 45 % デプロイの遅延 本番への遅延 © 2013 IBM Corporation 運用 / 本番 4~ 6 週間 コードを変更し、 リリースするまで
  • 「実用的なソフトウェア」を重視するということ は、 本番において実用的だということである 15 © 2013 IBM Corporation
  • DevOps: アジャイルが運用まで広がった なるほ ど! ビジネス・プロ セス ビジネス チーン! 運用 開発 アジャイル開発 これを修正する DevOps これを修正す る *image from Dev2Ops.org 16 © 2013 IBM Corporation
  • DevOps とは… • アジャイル & リーンが、開発者だけでなく、 ソフトウェア・デリバリー・チェーン全体に適用 – ビジネス・開発・品質・セキュリティー・リリース・運用 • 効率性と一貫性によって推進 • ソフトウェアのデリバリーをエンド・ツー・エンドで最適 化 17 © 2013 IBM Corporation
  • DevOps は破壊的である Dev (開発) Ops (運用) • 非常に速いテンポ  テンポが遅い • データベース / アプリケー ションを最初から再構築でき る  データベースとアプリケー ションに対して増分更新さ れる – • 18 – 監査はなくても支障がない – • ロールバックの必要がない ロールバックが膨大である  監査が重要 セキュリティー、追跡可能性、 職務の分離 – 新しい環境が一般的である セキュリティー、追跡可能性、職務 の分離  新しい環境は珍しい © 2013 IBM Corporation
  • デミングサイクル • • • ウイリアム・デミング - アメリカの統計学者 日本の製造業や商取引に大きな影響を与えた PDCA (計画、実行、評価、改善)サイクル (デミングサイクル)で有名 – • 19 私は「改善( Act )」より 「調整( Adjust )」と言う方が好きだ DevOps には PDCA サイクルがある © 2013 IBM Corporation 品質
  • DevOps アプローチ : 顧客との連続的なフィードバック・ループを生成す るために、 ソフトウェアのイノベーションとデリバリーにリーン原則を 適用する 1 1. アイデアを本番にすばやく 反映させる 2. 人々がそれを使用できるようにする 3. フィードバックを得る 2 事業部門 3 顧客 オーバーヘッドと再 修正 価値のある作業 20 DevOps アプローチを採用して、継続的 に変更を管理し、フィードバックを 入手し、 ユーザーに変更を知らせる 顧客が求めているこ とを知るのに必要で ない活動は取り除く © 2013 IBM Corporation
  • DevOps 市場機会を捉える時間と顧客のフィードバックを得る時間を短縮することを 可能とするための、継続的なソフトウェア・デリバリーを実現する企業規模の能力 DevOps ライフサイクル 顧客 事業部門 開発 / テスト 運用 / 本番 継続的なイノベーション、フィードバック、改善 ソフトウェア・デリバリーの加速 スピード、コスト、品質、およびリスクのバランス 顧客からフィードバックを得るまでの時間の短縮 21 © 2013 IBM Corporation
  • ツールの共有は難しい • 従来の硬直的な事業組織は、エンド・ツー・エンドのイ ンフラストラクチャーを制限してしまう可能性がある – 開発中心のツールは、データセンターでの使用に適さないこと がある – 運用中心のツールは、開発のためにデプロイされることが稀で ある 22 © 2013 IBM Corporation
  • 本番では、「 1 つのビルド」だけをデプロイし ていない 典型的な本番デプロイの取組みの範囲は? 単一のコンポ-ネント、サービス、ティアのデプロイ フルアプリケーションのデプロイ (いくつかのコンポーネントの可能性) システムのデプロイ(いくつかのアプリケーションを 含む) 無関係のものも含む場合がある、 複数のアプリケーションまたはシステムのデプロイ 1 回に 1 つのビルドを デプロイするのは 12 %しかない 23 © 2013 IBM Corporation
  • ニーズ : 本番に適したパイプライン・モデル 24 © 2013 IBM Corporation
  • ニーズ : 本番に適したパイプライン・モデル 25 © 2013 IBM Corporation
  • 統合されたパイプラインとスナップショットとの併 用 Web Snapshot Mid. Code 3 2 Mid. Config DB 26 3 1 © 2013 IBM Corporation 2
  • 今日のアジャイルおよび自動化 アジャイル ( Scrumban + DevOps ) • • • • • 27 小規模および大規模チーム ビジネスから運用まで 標準化 分散型 複数のビルドを本番に 自動化 (プロビジョン → 監視) • • • • Platform as a Service プロビジョン、ビルド、テス ト、 デプロイ、監視 エンタープライズ 共有化されたインフラストラ クチャー © 2013 IBM Corporation
  • 「本番」を意識してマニフェストを読む 我々は、ソフトウェア開発を自ら行い、また、開発を行う者を支援することにより 、 常にソフトウェア開発の改善を模索しています。 その際に我々が重視するのは以下の項目です。 プロセスやツールより人やコミュニケーション 包括的な文書より実用的なソフトウェア 契約交渉より顧客との連携 計画の実行より変化への対応 前者も重要ですが、我々は、後者の項目をより重視します。 28 © 2013 IBM Corporation
  • デリバリーパイプラインの能力:ツール 必要に応じて段階的に適用できます 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 © 2013 IBM Corporation
  • 30 © 2013 IBM Corporation
  • 31 © 2013 IBM Corporation
  • 関連展示のご案内 ただいまの講演に関連する展示は    となります。 01 04 14 第1会場 第 2 会 場 基調講演会場 第3会場 13 12 ソリューション・ツアー 受付 11 総合受付 10 09 08 Information Wall 07 06 05 04 DevOps ゾーン 03 02 01 © 2013 IBM Corporation ものづくり ゾーン
  • ワークショップ、セッション、および資料は、 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 © 2013 IBM Corporation