新型コロナウイルスによるパンデミックの発生やSNSの普及など、自然的にも人為的にも変化の大きい時代を迎えています。このように変化が大きい時代を迎える中、プロダクトの開発手法として「DevOps」が注目されています。本記事では、DevOpsのプロセスやツールの活用方法などについてご紹介していきます。
DevOpsとは
「DevOps」とは、開発チームを表す「Development」と、運用チームを表す「Operations」の2つの単語を組み合わせた言葉で、ソフトウェア・システム開発の現場において、ビジネスやユーザーの価値をより速く確実に届けるための概念を指します。
このDevOpsという言葉は、コンピュータ関連の技術書を出版していることで有名なオライリー社が2009年に開催したイベント「Velocity 2009」にて、FlickrのエンジニアJohn Allspaw氏とPaul Hammon氏が行った「10＋Deploys Per Day：Dev and Ops Cooperation at Flickr」という公演で初めて用いられたものです。
DevOpsの定義
ソフトウェア・システムの構築は、大きく「企画フェーズ」「開発フェーズ」「運用フェーズ」に分かれます。企画フェーズではビジネスやユーザー価値の実現を踏まえ、プロダクト設計を行います。開発フェーズまではエンジニアが開発を行い、テストが完了したプロダクトはある日を境にリリースされます。リリース後はユーザーが利用を開始し、この時点からシステムは運用フェーズに移ります。
運用フェーズ後もプロダクトの改善のために継続して開発が行われることが多く、開発チーム(Dev)と運用チーム(Ops)に分かれることが一般的です。しかし、開発チームのミッションはプロダクトに新しい機能を追加すること（変化を加える）であるのに対し、運用チームのミッションはプロダクトの安定稼働（変化させない）であるため、この目的の相違から往々にして対立構造がつくられます。
この対立構造が生じた場合、プロダクトの価値を提供するというそもそもの目的が、チーム間の軋轢により達成しにくくなります。この対立構造を解消するための考え方をDevOpsでは示していますが、その方法についてはプロダクトを開発するプロジェクトごとに千差万別の進め方があるため、厳密な定義は存在していません。
DevOpsの目的
DevOpsの目的は、迅速なプロダクト・サービスの提供により、プロダクトの価値を高めることにあります。そのためにはプロダクトを開発・リリースしてから、時間を空けることなくユーザーやビジネスに価値を与えているか検証し、繰り返し改善されたプロダクトを開発・リリースする必要があります。
「開発」→「リリース」→「検証」→「再度開発」というサイクルを回すことは、一見すると簡単なように思えますが、前述のとおり運用と並行して開発を進めることは困難を伴うため、DevOpsではこの点について解消を図ります。
アジャイル開発との違い
開発からリリース、検証のサイクルを考えると、「アジャイル開発」に近いものと思われるかもしれません。しかし、アジャイル開発は機能ごとの開発からテストまでのプロセスに注目した手法であるのに対して、DevOpsでは開発チームと運用チームがツールを活用しながら密に連携し、プロダクトの価値を高めていくことに注目している点が異なります。
そのためDevOpsでは、開発チームと運用チームで「互いを尊重する」「互いを信頼する」「失敗を認めない」「一緒に考える」という組織文化をつくる必要性についても語られています。
DevOps導入のメリット
DevOpsではコミュニケーションツールや、開発・リリース作業の自動化ツールが用いられます。コミュニケーションツールの利用により伝達モレがなくなり、開発・リリース作業の自動化により効率化を図りつつヒューマンエラーの低減も期待できます。
DevOpsでは、このようなツールを併用しながら開発チームと運用チームの連携を強化することで、短期間でプロダクトの価値を高めることが可能です。
DevOpsの具体的なプロセスとは
DevOpsには明確な定義がないため、明確な開発プロセスの定義もありませんが、こちらでは一般的なプロセスについてご紹介します。
計画（Plan）
計画プロセスでは、開発するプロダクトについてユーザーの要求を設定し、要件を定義していきます。また、要件からプロダクトに必要とされる機能を検討し、プロジェクトに必要とされる進捗管理やタスク管理の検討、開発プロセスのフレームワークの選定などを行い、このために必要となるツールを選定します。
開発（Development）
プロダクトを実現するためのコードや環境を作成するなど、開発を行うプロセスです。作成したコードをデグレーションが発生しないように管理し、ビルドとユニットテスト、インテグレーションテストを自動で1日に複数回行うことで、バグの発見を容易にします。発見されたバグは即座に修正することで、短期間で品質を保証することが可能です。
このような開発手法は「継続的インテグレーション（Continuous Integration / CI）」と呼ばれ、ビルドとテストを自動化するツールが用いられます。
配信（Deliver）
開発されたプロダクトはリリースされることで、ユーザーが利用可能となります。配信先はユーザーが利用する本番環境に限らず、開発者が動作確認をするための開発環境や、リリースを控えたプロダクトをステークホルダーが動作確認するための検証環境、不具合や新しい技術の動作を検証するためのサンドボックス環境など、多岐にわたります。
継続的インテグレーションを拡張し、変更・修正したプロダクトをビルドからデプロイまで誤ることなく各環境に反映することを「継続的デリバリー（Continuous Delivery / CD）」と呼び、こちらも同様に自動化するツールが用いられます。
運用（Operate）
プロダクトはリリースすれば終わりではなく、正常に可動しているか監視を続ける必要があります。そのための工程が、この運用プロセスです。プロダクトに過度なリクエストによるレスポンス悪化や、予期せぬデータの不整合などが発生していないか監視し、不具合が発生した場合は開発チーム・運用チームが連携してトラブルシューティングを行います。
また、ユーザーからのQAなどをもとにフィードバックを行い、継続的にプロダクトの改善に努めることも重要です。
DevOpsとCI/CDについて
DevOpsはCI/CDと合わせて語られることが多いため、CI/CDを行うことがDevOpsに値すると受け取られる場合があります。以下では、DevOpsとCI/CDの違いや、これらの実現におすすめのツールをご紹介します。
CI/CDとは
先述したとおり、CIは継続的インテグレーションを、CDは継続的デリバリーをそれぞれ意味する言葉です。いずれも自動化ツールを用いて効率的に作業を行うソフトウェア開発手法であり、プロダクトに加えられた変更を常にテストし、いつでも本番環境にリリース可能な状態にすることを表します。
DevOpsとCI/CDの違い
DevOpsとは、開発チームと運用チームが密に連携を取りながら開発を進める状態のことです。各チームが密に連携することで、プロダクトの不具合やユーザーからのフィードバックなどが滞りなく開発チームに伝わります。また運用チームも、開発の状況を把握しておくことで、いつ・どのように改善されたプロダクトがリリースされるかを理解できます。
このように開発チームと運用チームが互いを知り連携することで、プロダクトは短期間で改善され、価値を高められるのです。そして、開発を迅速化するだけでなく、短期間でプロダクトをユーザーのもとへ提供するために重要なのがCI/CDです。それゆえDevOpsでは一般的に、CI/CDについても合わせて語られます。
DevOpsのCI/CDを実現するツールJenkins
「Jenkins」は、オープンソースで提供されているオンプレミス型のツールです。汎用性が高く、ビルド・テスト・リリースを自動化でき、数百のプラグインが提供されていることから他ツールとの連携も容易です。
たとえばソースに修正が加えられた場合、「GitHubにコミットされた時点でビルドとテストを実行し、エラーがなければ検証環境へのリリースが終わり次第、Slackにリリース完了のメッセージを通知する」といった一連の作業を、ツールの違いを意識することなく自動化できます。
まとめ
DevOpsとは、開発だけでなく運用にも注目し、ツールを活用しながら効率的にプロダクトの価値を高めていくプロセスを説いたものです。そこで重要となるのがツール選びですが、今回ご紹介したJenkinsなら、多くの企業が採用する「Microsoft Azure」でもプラグインをサポートされているためおすすめです。
