1. 概要

この記事では、DevOpsの原則と実践の基本を理解します。 これがソフトウェア開発に関連し、役立つ理由を見ていきます。 また、DevOpsを有意義に採用する方法と、この旅に役立つツールが何であるかについても理解します。

2. 歴史的背景

歴史を少し振り返らなければ、今日のDevOpsを評価することはできません。 ソフトウェア開発の初期の頃は、主にウォーターフォール手法と呼ばれるものが特徴でした。 これが効果的に意味するのは、ソフトウェアが概念化され、設計され、開発され、テストされ、連続して配布されたということです

戻るには非常にコストがかかるため、すべてのステップが可能な限り詳細になりました。 これが効果的に意味したのは、思考と行動の間の待機期間がはるかに長いことでした。 ただし、これはそれほど問題ではありませんでした。テクノロジーランドスケープの変動がはるかに少なく、混乱が広すぎたためです。

興味深いことに、このモデルは長くは続かなかった。 テクノロジーのペースが変化し、混乱が頻繁に発生し始めると、企業は熱気を感じ始めました。 彼らは新しいアイデアをより速くテストする必要がありました。 これは、ソフトウェアを含むビジネスのすべての側面でより迅速な変更を意味しました。

これにより、アジャイルの傘下で大まかに見られるまったく新しいソフトウェア開発方法論の世界が生まれました。 アジャイルマニフェストは、ソフトウェアをより高速なフィードバックループで少しずつ提供するために従うべき一連の原則を示しています。 実際には、スクラムかんばんのようなアジャイルフレームワークがいくつかあります。

3. DevOps とは何ですか?

より高速なフィードバックを伴う段階的な開発が、今日のソフトウェア配信の基礎になっていることを確認しました。 しかし、どうすればそれを達成できますか? 従来のアジャイル方法論は私たちを合理的なポイントに導きますが、それでも理想的ではありません。

アジャイル手法は、サイロを壊そうと絶えず努力しているため、洗練され続けています。

従来、ソフトウェアの開発と提供を担当するさまざまなチームが常に存在していました。 これらのチームはしばしばサイロで活動していました。 これは効果的にはるかに長いフィードバックサイクルに変換されましたが、これはアジャイル手法では私たちが望んでいることではありません。

したがって、十分に統合されたクロスファンクショナルなアジャイルチームが目的を達成するのにはるかに適していることを理解するのに、多くの理由は必要ありません。 DevOpsは、ソフトウェア開発チームと運用チーム間のコミュニケーション、コラボレーション、統合、自動化を促進する手法です。 これにより、より高速なフィードバックで段階的な開発を実現できます。

次の図は、DevOpsを実践するための可能なワークフローを説明しています。

 

これらの手順の詳細についてはチュートリアルの後半で説明しますが、DevOpsの主要な原則のいくつかを理解しましょう。

  • 価値中心のアプローチ(エンドユーザーによって実現される)
  • 協調的な文化(効果的なコミュニケーション、プロセス、およびツールを使用)
  • プロセスの自動化(効率を高め、エラーを減らすため)
  • 測定可能な結果(目標に対して測定するため)
  • 継続的なフィードバック(迅速に改善する傾向がある)

4. 旅を始める方法は?

理論は単純で魅力的ですが、本当の課題はDevOpsを有意義に実践することです。 これまでに収集したように、 DevOpsは、チームではなく、主に人に関するものです。

共通の目的、効果的なコミュニケーション、および部門の枠を超えたスキルは、そのようなチームの特徴です。 この変化の大部分は文化的なものであるため、多くの場合、ゆっくりであり、摩擦がないわけではありません。

4.1. 動機

人気のある慣習があるからといって、必ずしもそれが私たちに適しているとは限りません。 アジャイルに向けて変化を起こす場合は、シフトの動機を理解する必要があります。 達成したい目標を定義して設定すると便利です

どの組織でもDevOpsの目標は、その組織の野心、文化、成熟度に依存します。 より一般的なDevOpsの目標のいくつかを次に示します。

  • エンドユーザーへのより良い体験
  • 市場投入までの時間の短縮
  • 平均修復時間の改善

4.2. 可決

DevOpsは最終状態ではなく、目標を達成するための継続的な改善プロセスであることを忘れないでください。 したがって、チームの全員が障害を特定し、迅速に取り除くために努力する必要があります。 これが私たちが始めるのを助けることができるいくつかの活動です:

  • 生産サイクルに対するアイデアの現状を明確に理解する
  • 明らかなボトルネックのいくつかを収集し、メトリックを使用して事実に基づく決定を行う
  • 削除したときに最大の価値を追加するボトルネックに優先順位を付ける
  • 優先項目の価値を段階的に提供するための反復計画を定義します
  • 目標を達成するために、開発-展開-測定の短いサイクルに従ってください

5. DevOpsプラクティス

従うべきいくつかの慣行がありますが、アイデアはゴールドスタンダードとしてそれらを使用するべきではありません。 私たちは、私たちの州と目的の背景にあるすべての慣行を注意深く調べてから、情報に基づいた決定を下す必要があります。 ただし、ほとんどすべてのプラクティスは、可能な限りプロセスの自動化に焦点を当てる傾向があります。

5.1. アジャイル計画

アジャイル計画は、作業を少しずつ定義する方法です。 最終的な目的は明確である必要がありますが、アプリケーション全体を事前に定義して詳細に説明する必要はありません。 ここで重要なのは、提供できる価値に基づいて作業に優先順位を付けることです

次に、短いが機能する増分の反復で分割する必要があります。

5.2. Infrastructure-as-Code(IaC)

これは、マシンで読み取り可能な構成ファイルを介してインフラストラクチャを管理およびプロビジョニングする方法です。 また、コードベースを管理するのと同じように、バージョン管理システムでこれらの構成を管理します。 これらの構成ファイルを宣言的に作成するために利用できるドメイン固有言語はたくさんあります。

5.3. テスト自動化

ソフトウェアテストは、従来、サイロで行われることが多い手動の作業でした。 これはアジャイルの原則とうまく調和しません。 したがって、単体テスト、機能テスト、セキュリティテスト、パフォーマンステストなど、すべてのレベルでソフトウェアテストを自動化するためにを試すことが不可欠です。

5.4. 継続的インテグレーション(CI)

継続的インテグレーションは、作業コードを少しずつ共有リポジトリにマージする方法です。 通常、この共有リポジトリでは自動ビルドとチェックが頻繁に実行され、コードの破損をできるだけ早く警告します。

5.5. 継続的デリバリー/デプロイメント(CD)

継続的デリバリーは、すべてのチェックに合格するとすぐにソフトウェアを少しずつリリースする方法です。 これは、継続的インテグレーションと一緒に実行されることが多く、自動リリースメカニズム(継続的展開と呼ばれる)の恩恵を受けることができます。

5.6. 継続的な監視

モニタリング(おそらくDevOpsの中心)により、より高速なフィードバックループが可能になります。 インフラストラクチャを含むソフトウェアのすべての側面を監視するための適切なメトリックを特定することが重要です。 適切な指標をリアルタイムで効果的な分析と組み合わせることで、問題をより迅速に特定して解決することができます。 さらに、アジャイル計画に直接反映されます。

このリストは完全ではなく、常に進化しています。 DevOpsを実践しているチームは、目標を達成するためのより良い方法を継続的に模索しています。 言及する価値のある他のプラクティスのいくつかは、いくつか例を挙げると、コンテナー化、クラウドネイティブ開発、およびマイクロサービスです。

6. 貿易の道具

ツールについて話さずに、DevOpsに関する議論を完了することはできません。 これは、過去数年間に爆発があった領域の1つです。 このチュートリアルを読み終える頃には、新しいツールがあるかもしれません。 これは魅力的であると同時に圧倒的ですが、注意を払う必要があります。

私たちの頭の中で最初にツールを使ってDevOpsの旅を始めてはなりません。 適切なツールを見つける前に、目標、人(文化)、および実践を調査して確立する必要があります。 それを明確にして、私たちが利用できる定評のあるツールのいくつかを見てみましょう。

6.1. 計画

これまで見てきたように、成熟したDevOpsは常にアジャイル計画から始まります。 目的は明確ですが、必要なのは、数回の短い反復で作業に優先順位を付けて定義することだけです。 これらの初期のイテレーションからのフィードバックは、将来のイテレーションと最終的にソフトウェア全体を形作る上で非常に貴重です。 ここでの効果的なツールは、このプロセスを簡単に実行するのに役立ちます。

Jiraは、Atlassianによって開発された一流の問題追跡製品です。多くのアジャイル計画および監視ツールが組み込まれています。 主に、これはオンプレミスで実行することも、ホストされたアプリケーションとして使用することもできる商用製品です。

6.2. 発達

アジャイルの背後にある考え方は、より高速にプロトタイプを作成し、実際のソフトウェアに関するフィードバックを求めることです。 開発者は、変更を加えて、ソフトウェアの共有バージョンにすばやくマージする必要があります。 チームメンバー間のコミュニケーションが流動的かつ迅速であることがさらに重要です。

このドメインのユビキタスツールのいくつかを見てみましょう。

Gitは分散バージョン管理システムです。かなり人気があり、gitリポジトリと付加価値機能を提供する多数のホスト型サービスがあります。 もともとLinusTorvaldsによって開発されたもので、ソフトウェア開発者間のコラボレーションが非常に便利になります。

Confluenceは、Atlassianによって開発されたコラボレーションツールです。 コラボレーションは、アジャイルチームの成功の鍵です。 コラボレーションの実際のセマンティクスはかなり状況に応じたものですが、それでも、作業をシームレスにするツールは非常に貴重です。 Confluenceはこのスポットに正確に適合します。 さらに、Jiraとうまく統合できます!

Slackは、Slack Technologiesによって開発されたインスタントメッセージングプラットフォームです。前述したように、アジャイルチームは、できればリアルタイムでコラボレーションおよび通信できる必要があります。 インスタントメッセージングとは別に、Slackは、単一のユーザーまたはユーザーのグループと通信するための多くの方法を提供します。また、JiraやGitHubなどの他のツールとうまく統合できます。

6.3. 統合

開発者によってマージされた変更は、コンプライアンスについて継続的に検査する必要があります。 コンプライアンスを構成するものは、チームとアプリケーションに固有です。 ただし、コンプライアンスのコンポーネントとして、静的および動的なコード分析、および機能的および非機能的なメトリック測定を見るのが一般的です。

人気のある統合ツールをいくつか簡単に見てみましょう。

Jenkinsは、魅力的でオープンソースの無料の自動化サーバーです。何年にもわたって業界に存在し、幅広い自動化のユースケースに対応できるほど成熟しています。 自動化ルーチンを定義する宣言型の方法と、自動または手動でトリガーするさまざまな方法を提供します。 さらに、強力な自動化パイプラインを作成するためのいくつかの追加機能を提供するプラグインの豊富なセットがあります。

SonarQubeは、SonarSourceによって開発されたオープンソースの継続的検査プラットフォームです。 SonarQubeには、多くのプログラミング言語用の豊富な静的分析ルールのセットがあります。 これにより、コードの臭いをできるだけ早く検出できます。 さらに、SonarQubeは、コードカバレッジ、コードの複雑度などの他のメトリックを統合できるダッシュボードを提供します。 そして、それはJenkinsサーバーでうまく機能します。

6.4. 配達

変更や新機能をソフトウェアに迅速に提供することが重要です。 リポジトリにマージされた変更が標準とポリシーに準拠していることを確認するとすぐに、エンドユーザーに迅速に配信できるようになります。 これは、フィードバックを収集し、ソフトウェアをより適切に形成するのに役立ちます。

ここには、継続的デプロイを実現するまでの配信のいくつかの側面を自動化するのに役立つツールがいくつかあります。

Dockerは、あらゆるタイプのアプリケーションをすばやくコンテナ化するための一般的なツールです。 OSレベルの仮想化を活用して、コンテナと呼ばれるパッケージ内のソフトウェアを分離します。 コンテナ化には、より信頼性の高いソフトウェア配信という点ですぐにメリットがあります。 Dockerコンテナーは、明確に定義されたチャネルを介して相互に通信します。 さらに、これは仮想マシンのような他の分離方法と比較してかなり軽量です。

Chef / Puppet / Ansibleは構成管理ツールです。ご存知のように、ソフトウェアアプリケーションの実際に実行されているインスタンスは、コードベースビルドとその構成の組み合わせです。 また、コードベースのビルドは環境間で不変であることがよくありますが、構成は不変ではありません。 ここで、アプリケーションを簡単かつ迅速に展開するための構成管理ツールが必要です。 このスペースにはいくつかの人気のあるツールがあり、それぞれに癖がありますが、Chef、Puppet、およびAnsibleがベースをほぼカバーしています。

HashiCorp Terraformは、インフラストラクチャのプロビジョニングを支援します。これは、プライベートデータセンターの時代から退屈で時間のかかる作業でした。 しかし、クラウドの採用が増えるにつれ、インフラストラクチャは使い捨てで繰り返し可能な構造と見なされることがよくあります。 ただし、これは、ツールを使用して、単純なインフラストラクチャから複雑なインフラストラクチャを宣言的に定義し、ボタンをクリックするだけで作成できるツールがある場合にのみ実現できます。 夢のシーケンスのように聞こえるかもしれませんが、Terraformは積極的にそのギャップを埋めようとしています!

6.5. モニタリング

最後に、展開を観察し、ターゲットに対して測定できることが不可欠です。 システムやアプリケーションから収集できる多くのメトリックが存在する可能性があります。 これらには、アプリケーションに固有のビジネスメトリックの一部が含まれます。

ここでの考え方は、これらのメトリックをほぼリアルタイムで収集、キュレート、保存、および分析できるようにすることです。 このスペースで利用できる、オープンソースと商用の両方のいくつかの新製品があります。

Elastic-Logstash-Kibana(ELK)は、Elasticsearch、Logstash、Kibanaの3つのオープンソースプロジェクトのスタックです。 Elasticsearchは、拡張性の高い検索および分析エンジンです。 Logstashは、さまざまなソースからのデータを消費できるサーバー側のデータ処理パイプラインを提供します。 最後に、Kibanaはこのデータを視覚化するのに役立ちます。 一緒に、このスタックを使用して、すべてのアプリケーションからのログなどのデータを集約し、リアルタイムで分析することができます

Prometheusは、SoundCloudによって開発されたオープンソースのシステム監視およびアラートツールです。 多次元データモデル、柔軟なクエリ言語が付属しており、HTTPを介して時系列データを取得できます。 Grafanaは、複数のデータベースで機能するもう1つのオープンソースの分析および監視ソリューションです。 PrometheusとGrafanaを組み合わせることで、システムが生成できるほぼすべてのメトリックをリアルタイムで処理できます。

7. DevOps拡張機能(または実際にそうですか!)

DevOpは、基本的に、ソフトウェアのより高速で反復的な価値ベースの配信に向けた障害を取り除くための継続的な取り組みであることがわかりました。 さて、当面の結論の1つは、ここに最終状態はあり得ないということです。

開発チームと運用チームの間の摩擦として人々が認識したのは、摩擦だけではありません。 コラボレーションを強化するために組織内のサイロを破ることが中心的なアイデアです。 今、人々はすぐに開発チームとテストチームの間、および開発チームとセキュリティチームの間に同様の摩擦が存在することに気づき始めました。 従来のセットアップの多くには、専用のセキュリティチームとパフォーマンスチームがあります。

チーム間のほぼすべての境界を打ち破り、チームがより効率的にコラボレーションできるようになるまで、DevOpsの可能性を最大限に引き出すことはできません。 これは本質的に、テスト、セキュリティ、パフォーマンスなどのチームを折り畳むことを意味します

混乱は主にその命名法にあります。 DevOpsは、それが主に開発チームと運用チームに関するものであることを理解させてくれます。 したがって、時間の経過とともに、他のチームを含む新しい用語が出現しました。 しかし、主に、DevOpsがより効果的に実現されているだけです!

7.1. DevTestOps

DevOpsの要は、高品質のソフトウェアを少しずつそしてより頻繁に提供することです。 ここで品質を重視することには多くの側面があります。 ある意味で、私たちが採用するDevOpsプラクティスは、これを達成するのに役立つと考えることがよくあります。 また、前述のプラクティスの多くは、常に高品質を確保することに重点を置いていることも事実です。

しかし、ソフトウェアの機能テストの範囲ははるかに広いです。 多くの場合、ソフトウェア配信の終わりに向けて、エンドツーエンドのテストなどの高次のテストを継続する傾向があります。 さらに重要なことに、これは多くの場合、プロセスの後半に従事する別のチームの責任です。 これは、物事がDevOpsの原則から逸脱し始めるところです。

私たちがやるべきことは、最初からソフトウェアテストをすべてのレベルで統合することです。 計画段階から、ソフトウェアテストは配信の不可欠な側面と見なす必要があります。 さらに、同じチームがソフトウェアの開発とテストを担当する必要があります。 これは、DevTestOpsの実践が広く知られているものです。 これは、継続的テストおよび左シフトとも呼ばれます。

7.2. DevSecOps

セキュリティはソフトウェア開発の不可欠な部分であり、複雑さを共有しています。 これは多くの場合、製品を出荷する準備ができたときにすぐに関与するセキュリティスペシャリストの別のチームがあることを意味します。 この段階で特定された脆弱性は、修正に費用がかかる可能性があります。 これもまた、DevOpsの原則とうまく共鳴しません。

この時点で、適用する必要のあるソリューションがすでに用意されているはずです。つまり、ゲームの早い段階でセキュリティ上の懸念と人員を持ち込む必要があります。 チームがあらゆる段階でセキュリティについて考えるように動機付ける必要があります。 セキュリティは間違いなく非常に専門的なドメインであるため、チーム内に専門家を雇う必要があるかもしれません。 ただし、ここでの考え方は、最初からいくつかのベストプラクティスを検討することです。

進むにつれて、脆弱性の大部分のスキャンを自動化できる[X128X]いくつかのツールが利用可能になります。 これを継続的インテグレーションサイクルにプラグインして、迅速なフィードバックを取得することもできます。 現在、継続的インテグレーションを軽量に保つ必要があるため、すべてを継続的インテグレーションに統合することはできませんが、他の定期的なスキャンを個別に実行することは常に可能です。

8. 結論

この記事では、DevOpsの原則、実践、および使用可能なツールの基本について説明しました。 DevOpsが関連するコンテキストと、DevOpsが役立つ理由を理解しました。 また、DevOpsを採用する過程でどこから始めればよいかについても簡単に説明しました。

さらに、この旅で使用できる人気のあるプラクティスとツールのいくつかに触れました。 また、DevTestOpsやDevSecOpsなどのDevOpsに関するその他の一般的な用語のいくつかも理解しました。

最後に、DevOpsは最終状態ではなく、決して終わらない可能性のある旅であることを理解する必要があります。 しかし、ここでの楽しい部分は旅そのものです。 その間、私たちは自分たちの目標を見失うことは決してなく、重要な原則に焦点を当てるべきです。 業界で人気のあるツールや用語の輝きに陥るのは非常に簡単です。 しかし、私たちは常に、それが私たちの聴衆により効率的に価値を提供するのに役立つ場合にのみ有用であることを覚えておく必要があります。