「DevOps」の版間の差分
削除された内容 追加された内容
編集の要約なし |
Irgenwodubist (会話 | 投稿記録) m リンク |
||
19行目:
#モニター ： アプリの性能監視、エンドユーザーエクスペリエンス
利用可能なツールは多数あるが、会社・組織でDevOpsツールチェーンを利用するには、カテゴリの特定が必要となる。その基本的なツールを特定する方法は既存の文献で探すことができる。DevOpsの実現には[[構成管理]]ツールである[[Docker]]（コンテナリゼーション）、
==アジャイルソフトウェア開発・継続的デリバリーとの関係==
28行目:
DevOpsに関わる多くの考え方や関係者は、エンタープライズシステムの管理とアジャイルソフトウェア開発の潮流のなかから生まれた。
===継続的デリバリー===
DevOpsと継続的デリバリーはともにアジャイルメソッドと[[リーン生産方式]]を背景としているため、間違われやすい。似てはいるが、異なる概念である<ref name="AgileInf2010"/>
DevOpsはより広い範囲を対象にしており、主なポイントは：
*組織改革：ソフトウェアデリバリーに関わるさまざまなチーム（開発、IT運用、品質保証・QA、管理など）の協力を育む
41行目:
*新しいリリース時の失敗率低減
*修正の間にリードタイムを短縮
*回復時間の短縮（新しいリリースでクラッシュしたり、現在のシステムを無効にすることがある場合
DevOpsアプローチを使用することで、シンプルなプロセスであってもよりプログラムの可用性が高まり、ダイナミックなプロセスになる。DevOpsは運用プロセスの予測可能性、効率性、セキュリティ、又は保守性を最大化することを目指している。しばしば、自動化がこの目標を支援する。
また別の目標として、信頼性とセキュリティを改善しながら、迅速な開発と展開サイクルを提供することがある。そのために、DevOpsの統合は、製品の出荷、継続的なテスト、品質テスト、機能開発、又はメンテナンスリリースを対象としている。
62行目:
DevOpsの原則は強力な部門間のコミュニケーションを要求するため、チームビルディングや他の従業員参加活動がしばしば利用される。チームビルディング活動にはボードゲーム、信頼活動、従業員参加セミナーなどがある。強力な部門間のコミュニケーションを育むことで、文化の変化を促進する環境を作り出すことができる。
===展開===
非常に多くのリリースを有する企業では、DevOpsの意識啓発プログラムが必要になる場合がある。例えば、DevOpsという単語は2009年の[[オライリーメディア|オライリー]]主催のイベント「Velocity 2009」において、画像ホスティングWebサイト[[Flickr]]のエンジニアにより初めて公の場で用いられた。この[[プレゼンテーション]]では「開発と運用が協力することで、1日に10回以上のペースでのリリースが可能になる」という発表とともにDevOpsという単語が用いられた。毎日の展開サイクルは、マルチフォーカスまたはマルチファンクションアプリケーションを作成する組織では多いだろう。それは、継続的な展開又は継続的なデリバリーと呼ばれて、[[リーンスタートアップ]]方法論に関連付けられている。 2009年の会議以降、ワーキンググループ、プロフェッショナルな協会やブログ上で話題となっている。
==DevOpsとアーキテクチャ==
DevOpsを効果的に実践するためには、ソフトウェア・アプリケーションはアーキテクチャ上重大な要求（ASR）と呼ばれている要求を満たす必要がある。展開性、修正可能性、テスト容易性、と監視性などASRは高い優先度を必要とする<ref name="ArchCD_LC">{{cite conference |url=http://dx.doi.org/10.1109/WICSA.2015.23|title=Towards Architecting for Continuous Delivery|first=Lianping |last=Chen|year=2015|place=Montréal, Canada |conference=The 12th Working IEEE/IFIP Conference on Software Architecture(WICSA 2015)|conferenceurl=http://wicsa2015.org/ |publisher=IEEE}}</ref>
基本的には、どのようなアーキテクチャ・スタイルでも、DevOpsを実践することは可能である。しかし、展開されるシステムを構築する場合の[[マイクロサービス|マイクロ・サービス]]のアーキテクチャ・スタイルが標準になりつつある。各サービスのサイズが小さいため扱いやすくなり、そして、継続的な編集を通じて、各サービスのアーキテクチャが見えるようになる。そのため、大きな初期設計が不要となり、ソフトウェアを早期に継続的にリリースすることができる。
==導入の範囲==
DevOpsの文献には、組織のIT部門以外からのDevOpsイニシアチブへの重要な参加が必要だと勧めている記事がある。例えば、「DevOpsは、企業全体にもたらされたアジャイルの原則である」というメッセージがある。<ref>{{Cite web | url = http://devops.com/2015/03/04/devops-is-agile-for-the-rest-of-the-company/ | title = DevOps is Agile for the Rest of the Company | publisher = DevOps.com| accessdate=31 march 2016}}</ref>もう一つの広い範囲からの参加の例は、内部資金調達プロセスへの変更：「資金調達は通常滝のように提供される。しかし、継続的デリバリー・モデルには、適していない確定日付（月、四半期、会計年度、など）というゲートがあるので、資金調達も継続的でなければならない。」<ref>{{cite journal|last=Harvey |first=Cynthia | date= 9 January 2017 | title= 10 Ways DevOps is Changing the Enterprise | url= http://www.datamation.com/data-center/slideshows/10-ways-devops-is-changing-enterprise-it.html | journal=Datamation }}</ref>
| |||