DevOps パイプライン

DevOps パイプラインは、一連の自動化されたプロセスとツールであり、開発者と運用担当者が共同でコードを構築して本番環境にデプロイするのをサポートするものです。

Krishna Sai の顔写真
Tom Hall

DevOps アドボケート & 実践者


DevOps は、開発と運用が分離されたサイロ化組織構造に革命をもたらすという点で、革新的な動きです。その結果、開発者と運用担当者が協力して自動化を採用し、デプロイを加速させて柔軟性を高める文化的な変化が生まれます。

その結果として生じる DevOps 構造には、明らかなメリットがあります。DevOps プラクティスを採用するチームはデプロイ パイプラインの改善と合理化ができるため、インシデントの頻度と影響が軽減されます。「構築した者が運用する」という DevOps のプラクティスは瞬く間に標準になりつつあり、それも当然の理由があります。2020 年の DevOps 動向調査の回答者ほぼ全員 (99%) が「DevOps は組織にプラスの影響を与えた」と、半数近くが「市場投入までの時間の短縮とデプロイ頻度の改善が見られた」と回答しています。

ただし、DevOps の実装は口で言うほど簡単ではありません。DevOps をうまく実装するには、適正な人材、プロセス、ツールが必要です。

DevOps パイプラインとは


DevOps パイプラインは、一連の自動化されたプロセスとツールであり、開発者と運用担当者が密に連携してコードを構築して本番環境にデプロイするのをサポートするものです。DevOps パイプラインは組織によって異なりますが、一般的にはビルドの自動化/継続的インテグレーション自動テスト、検証、レポート生成で構成されます。また、コードの処理を進める前に人間の介入を必要とする手動ゲートが 1 つ以上含まれている場合があります。

"継続的" は DevOps パイプラインの差別化された特性です。これには、継続的インテグレーション、継続的デリバリー/デプロイ (CI/CD)、継続的なフィードバック、継続的な運用が含まれます。1 回限りのテストや予定デプロイではなく、各機能は継続的に実行されます。

連結された輪のアイコン
関連資料

無料で始める

ツールアイコン
関連資料

DevOps ツールの詳細

DevOps パイプラインを構築する際の考慮事項


1 つの標準的な DevOps パイプラインがあるわけではないため、組織の DevOps パイプラインの設計と実装は、その組織のテクノロジー スタック、DevOps エンジニアの経験レベル、予算などによって決まります。DevOps エンジニアは、コーディング、インフラストラクチャ管理、システム管理、DevOps ツールチェーンなど、開発と運用の両方に関する幅広い知識を持っている必要があります。

さらに、組織ごとに異なるテクノロジー スタックがあり、プロセスに影響を与える可能性があります。たとえば、コードベースが node.js の場合は、ローカル プロキシ npm レジストリを使用するどうか、ソース コードをダウンロードして `npm install` をパイプラインのすべての段階で実行するか、または一度実行してパイプライン内を移動するアーティファクトを生成するか、などの要因があります。または、アプリケーションがコンテナーベースの場合は、ローカルまたはリモートのコンテナー レジストリを使用するか、コンテナーを一度構築してパイプライン内を移動させるか、またはすべての段階で再構築するかを決定する必要があります。

DevOps パイプラインはコミット、構築、ユニット テスト、トランクへのマージ、統合テスト、ステージング、回帰テスト、デプロイで構成されます。いずれかの段階でテストが失敗するとパイプラインは停止され、開発者にフィードバックが提供されます。

パイプラインはそれぞれ異なりますが、ほとんどの組織は似たような基本コンポーネントを使用しています。パイプラインの次の段階に進む前に、各ステップの成否が評価されます。障害が発生した場合、パイプラインは停止されて開発者にフィードバックが提供されます。

DevOps パイプラインのコンポーネント


1. 継続的インテグレーション/継続的デリバリー/デプロイ (CI/CD)

継続的インテグレーション とは、共通のソース コード リポジトリに対して頻繁にコミットするプラクティスです。コードの変更を既存のコードベースに継続的に統合するために、異なる開発者のコード変更間の競合を迅速に特定して、比較的簡単に修正できます。このプラクティスは、デプロイの効率を高めるために非常に重要です。

トランクベース開発は継続的インテグレーションの要件と考えられます。共有ソース コード リポジトリの共通ブランチに頻繁にコミットしない場合は、継続的インテグレーションを行っているとは言えません。構築プロセスとテスト プロセスが自動化されていても、開発者が分離されたフィーチャー ブランチで長期的に作業していて共有ブランチにはほとんど統合されない場合も、継続的インテグレーションは行われていません。

継続的デリバリーは、アプリケーションのソース コードの "メイン" または "トランク" ブランチを、常にリリース可能な状態にしようとする試みです。言い換えれば、経営陣が金曜日の午後 4 時 30 分にデスクに来て「最新バージョンを今すぐリリースする必要がある」と宣言しても、ボタンを押すだけで、障害を恐れることなくそのバージョンをデプロイできます。

このためには、本番環境にできるだけ近い本番前環境を用意し、自動テストが実行されるようにして、コードがメイン ブランチまたはトランク ブランチにマージされる前に、障害を引き起こす可能性のあるすべての不確定要素を特定しておきます。

継続的デプロイは、継続的なテストと運用のレベルを非常に堅牢にして、人間の手を借りずに新しいバージョンのソフトウェアを検証して本番環境にデプロイするというものです。

これを使用するのは稀で、ほとんどの場合は不要です。通常、このレベルの自動化を必要とする (または希望する) のは、数百人、数千人もの開発者を抱える、毎日多数のリリースがあるユニコーン企業だけです。

継続的デリバリーと継続的デプロイの違いを単純化して説明するなら、デリバリーは宅配業者が荷物を届けること、デプロイはその荷物を開封して中身を使うことだと考えてください。もし荷物を受け取ってから開封するまでの間に製品の変更が必要になれば、メーカーは厄介なことになります。

2. 継続的フィードバック

従来のウォーターフォール方式によるソフトウェア開発の最大の弱点であり、結果的にアジャイル手法が設計された理由にもなっているのは、タイムリーなフィードバックの欠如でした。新しい機能のアイデアから実装までに数か月または数年かかる場合、最終製品は顧客が期待していたものや望んでいたものとは別のものになることはほぼ間違いありません。アジャイルは、開発者が関係者からより迅速なフィードバックを受け取れるようにすることに成功しました。DevOps により、開発者は関係者からだけでなくパイプラインにおけるコードの体系的なテストと監視からも継続的なフィードバックを受け取れます。

継続的なテストは、すべての DevOps パイプラインの重要なコンポーネントであり、継続的なフィードバックを実現する主な要素でもあります。DevOps プロセスでは、変更が開発からテスト、デプロイへと継続的に移動するため、リリースの迅速化だけでなく製品の品質向上にもつながります。これは、すべてのビルド変更で実行されるユニット テスト、スモーク テスト、機能テスト、エンドツーエンド テストなど、パイプライン全体でテストを自動化することを意味します。

継続的なモニタリングは、継続的なフィードバックのもう 1 つの重要なコンポーネントです。DevOps のアプローチでは、ステージング、テスト、さらには開発環境における継続的なモニタリングの使用も伴います。本番前環境で異常な動作がないかを監視することが役立つ場合もありますが、一般的には、これは本番環境のアプリケーションの健全性とパフォーマンスを継続的に評価するために使用されるアプローチです。

この機能を提供するツールやサービスは数多く存在します。これは、サーバー リソースやネットワーキングなどのオンプレミスまたはクラウドのインフラストラクチャの監視から、アプリケーションや API インターフェイスのパフォーマンスの監視まで、多岐にわたります。

3. 継続的な運用

継続的な運用は比較的新しく、あまり一般的でない用語であるため定義もまちまちです。1 つの解釈としては "継続的なアップタイム" があります。たとえば、ブルー/グリーン デプロイ戦略の場合は、"ブルー" (パブリック アクセス可能) と "グリーン" (パブリック アクセス不可) の 2 つの本番環境があります。この状況では、新しいコードがグリーン環境にデプロイされ、それが機能することが確認されるとスイッチが (通常はロードバランサで) 切り替えられ、トラフィックが "ブルー" システムから "グリーン" システムに切り替わります。その結果、エンドユーザーのダウンタイムは発生しません。

継続的な運用のもう 1 つの考え方は、継続的なアラートです。これは、アプリケーションまたはインフラストラクチャでパフォーマンスの異常が発生した場合、エンジニアリング スタッフはオンコールで通知を受けるという概念です。ほとんどの場合、継続的なアラートは継続的な監視と連動します。

結論


DevOps は、ソフトウェアの開発、デプロイ、運用を合理化するためのものです。DevOps パイプラインとは、これらのアイデアをプラクティスに実装する方法であり、コードの統合からアプリケーションの運用まですべてが継続的ということが最も重要な点です。

継続的デリバリーの詳細については、Bitbucket を使用した継続的デリバリーのチュートリアルをご確認ください。このチュートリアルでは、統合 CI/CD で構築、テスト、デプロイを実施できます。これらのチュートリアルは、初心者にとってもプロにとっても Bitbucket で継続的デリバリーを実現するのに役立ちます。利用を開始する準備はできていますか? Bitbucket Pipelines のご利用は無料です。

Tom Hall
Tom Hall

Tom Hall は DevOps アドボケートかつ実践者であり、熱心な読書家、そしてアマチュア ピアニストでもあります。
過去 20 年間にわたる実績には、Novell、EMC、VMware、AWS の認定が含まれます。2016 年にアトランタで DevOpsDays の企画をサポートして以降、テキサス州オースティンの開催を何年もサポートしてきました。


この記事を共有する
次のトピック

おすすめコンテンツ

次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。

DevOps のイラスト

DevOps コミュニティ

DevOps のイラスト

DevOps ラーニング パス

マップのイラスト

無料で始める

DevOps ニュースレター購読

Thank you for signing up