記事
チュートリアル
インタラクティブ ガイド
DevOps ツールチェーンに関する考慮事項
選ぶべきはオールインワンか、カスタマイズ可能な DevOps ツールチェーンか?
Robert Krohn
DevOps 担当エンジニアリング部長
寄稿、編集: Chandler Harris
DevOps ツールチェーンはさまざまなベンダーのツールのコレクションで、ソフトウェアとシステムを設計、構築、テスト、管理、測定、運用するための統合ユニットとして動作します。これにより、開発チームと運用チームが製品ライフサイクル全体にわたってコラボレーションし、継続的インテグレーション、継続的デリバリー、自動化、コラボレーションなどの DevOps の主な基本要素に対応できます。
アジャイルから DevOps へ
アジャイルの原則が広く導入されると、製品の開発方法に革命がもたらされました。少人数の部門横断型チームと 1 ～ 2 週間のスプリントを導入することで、本番環境への準備が整った成果物を生み出しました。また、タイトなフィードバック サイクルと継続的な改善がありました。そして、製品のデリバリーが速くなり、頭痛の種が減りました。
物事の変化の速さには驚くばかりです。クラウド、SaaS、常時稼働サービスにより、開発ライフサイクルが大幅に短縮されました。複数の開発段階とテスト段階が同時に進められるのも珍しくありません。アジャイルには通常 1 ～ 2 週間のスプリントがありましたが、今日のクラウド ネイティブ環境のチームは、1 日に複数回イテレーションとデプロイを行います。ワークフローとコードベースは絶えず進化しています。チームは、機能フラグ、プログレッシブ ロールアウト、A/B テストを使用して、クリーンで高品質なコードを継続的にデプロイできるようにします。
これがアジャイルから DevOps への進化を生みました。DevOps はソフトウェア開発と IT チーム間のプロセスを自動化して統合するプラクティスを 1 つにまとめたもので、より短時間かつ確実にソフトウェアを構築、テスト、リリースできるようにするものです。DevOps チームは、本番環境へコードをいかに迅速にプッシュできるかで評価されます。評価基準は、毎日リリースされるイテレーションの回数と、コードの変更がテストからデプロイを経て本番環境に移行するまでの所要時間です。当執筆者が在籍するチームを例にすれば、典型的なプロジェクトでは 1 日あたり最大 20 件の変更が生じます。一部の大規模なプロジェクトでは、1 日あたり最大 100 件の変更が生じます。
この高速化されたワークフローは、開発、テスト、デプロイ全体でチームのコラボレーションを可能にする新しいツールによって実現し、こうしたツールに依存しています。特に、DevOps ツールチェーンによって、チームは開発ライフサイクルの各段階に、非常に迅速に取り組めます。
DevOps ツールチェーンとは
DevOps ツールチェーンには、開発チームと運用チームがソフトウェアのライフサイクル全体にわたってコラボレーションできるようにするツールとテクノロジーが含まれています。これにより、継続的インテグレーション、継続的デリバリー、自動化、コラボレーションなど、DevOps の主な基本要素に対応できます。
DevOps は、開発と運用が統合ユニットとして機能する文化的なシフトであるため、DevOps の原則とプラクティスを実現する単一のツールはありません。代わりに、DevOps ツールチェーンはさまざまなベンダーのツールのコレクションで、ソフトウェアとシステムを設計、構築、テスト、管理、測定、運用するための統合ユニットとして動作します。多くの場合、組織やチームは適切なツールチェーンを見つけるために、さまざまなツールの組み合わせを試す必要があります。
高度な DevOps 製品を見渡すと、DevOps ツールチェーンは開発ライフサイクルのさまざまな部分にすばやく対応して、さまざまなユーザーにさまざまな観点を提供できるはずです。これには、継続的インテグレーション/デリバリー、テストの自動化、高速デプロイなど、開発ライフサイクルの各フェーズに対応する開発ツールが含まれている必要があります。DevOps の運用面では、監視とインシデント管理に役立つ機能を備えたツールが必要です。さらに、ツールは継続的なフィードバックとログを提供することで、開発と運用の橋渡しの役を果たす必要があります。
関連資料
無料で始める
関連資料
統合を確認する
上の無限ループ図の左側を製品側、右側を運用側と考えると、新しい機能を本番環境にプッシュするプロダクト マネージャーの関心は、プロジェクトがタスクとユーザー ストーリーにどのように分割されるかにあります。プロジェクトの左側の開発者は、プロジェクト チケット、ユーザー ストーリー、依存関係など、機能を本番環境に移行する方法を確認する必要があります。"構築した者が運用する" という DevOps の原則に従えば、開発者はインシデントの修復にも関心を持ちます。
ライフサイクルの運用側に移ると、サイト信頼性エンジニアは測定と監視が可能なサービスを理解して、問題が発生した場合は修正できるようにする必要があります。これらすべてのプロセスを結び付けるツールチェーンがないと、乱雑で相関性のない混沌とした環境になります。適切に統合されたツールチェーンがあれば、今起きている状況をより理解しやすくなります。
DevOps ツールチェーン構築のオプション
適切な DevOps ツールチェーンを決定するには、まず基本的な DevOps ベスト プラクティスを認識し、ツールがそれらのプラクティスにどのように貢献するかを理解することが重要です。次に、開発、テスト、デプロイ全体でチームのコラボレーションを可能にする共通のツール戦略を確立します。
組織が DevOps を採用する場合は、通常、"オールインワン" の DevOps ツールチェーンか、カスタマイズされた DevOps ツールチェーンの 2 つの選択肢があります。構成はチームの DevOps プロセスを形作るため、適切な構成を選択することが重要です。
オールインワン DevOps ツールチェーン
オールインワン DevOps ソリューションは、包括的な 1 つのソリューションであり、他のサードパーティ製ツールとは統合できない可能性があります。これは、DevOps ジャーニーを始めたばかりの企業やグループ、またはプロジェクトをすぐに開始したいチームにとって便利です。このタイプのツールチェーンの欠点は、確立されたチームのほとんどは既に使い慣れたツールセットを持っており、それを包括的なソリューションと統合できない可能性があるという点です。さらに、このような包括的なツールチェーンは、"何でもできるは何もできない" 症候群を生む可能性があります。1 つのツールでは、急速に変化する市場に対応した進化ができません。結局、企業はレガシー ツールを DevOps ツールチェーンに統合することを迫られる場合も多いのですが、オールインワンのツールチェーンがその妨げになる恐れがあります。
カスタマイズ可能な DevOps ツールチェーン
もう 1 つのアプローチは、チームのニーズに合わせてさまざまなツールでカスタマイズできる DevOps ツールチェーンを使用することです。これにより、チームは使い慣れた既存のツールを幅広い DevOps ツールチェーンに取り入れられます。たとえば、チームは、計画とワークフローの追跡に Jira、個々の開発環境のプロビジョニングに Kubernetes、コラボレーション コーディングに Github、継続的インテグレーションに Jenkins を使用する、といったことができます。組織は、チームやプロジェクトごとにワークフローをカスタマイズできます。
これらのタイプのツールチェーンには統合が不可欠です。複数の異なるツール間の統合が行われていないと、チーム メンバーは画面の切り替えや複数サイトへのログインに無駄な時間を費やすことになり、ツール間で情報を共有することが難しくなる場合があります。これは、開発者をはじめ、現状を把握しようとする人にとって望ましい状態ではありません。インシデントに対応する際には、マニュアルを見て新しいツールに関する重要な情報を探す時間などありません。
結論
DevOps は、部門横断型であれ 1 つのチーム内であれ、サイロを分解して開発ライフサイクルをより速く高度に自動化し、シームレスにコラボレーションできるようにします。連携して機能する適切な DevOps ツールを選択するには、何よりもまず現在のソフトウェア開発と IT 運用プロセスを厳しい目で点検して、改善すべき点を決定します。
DevOps ライフサイクルの各フェーズに適したツールの詳細をご確認ください。
この記事を共有する
次のトピック
おすすめコンテンツ
次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。
DevOps コミュニティ
DevOps ラーニング パス
