DevOpsを始めるときに「何をやるべきか」を理解しよう

はじめに

「これからプロジェクトでDevOpsを実践しよう」としたとき、どのような技術や知識が必要になるのか、何をしなければいけないのか、色々と調べるかと思います。世の中にはDevOpsに関するWeb記事や書籍は数多くあり、それらから十分に知識を得ることができます。しかし、実際にプロジェクトを立ち上げ、推進していくためには具体的に何を行うべきか、何を考慮すべきといった情報はあまり世の中に流通していません。

そこで、本連載ではプロジェクト運営、インフラエンジニア、開発者のそれぞれの視点から、DevOpsを始めるにあたって具体的に何を考慮すべきかを紹介していきます。第1回の今回は、プロジェクト運営の立場から決めるべきことを紹介します。

DevOpsを実現するために必要な人材と知識

まずは、プロジェクトの体制について考えてみたいと思います。DevOpsをプロジェクトに適用しようとした場合、必要となる人材やその人材が持つべきスキルセットがどのように変わるかを理解する必要があります。従来の開発の延長線上にありつつも、新しいパラダイムを伴うDevOpsを実現するためには、既存のチームの役割からDevOpsを実践するためのチームの役割への認識のアップデートが必要となります。

図1：Devの役割とOpsの役割

DevOpsにおけるDevとOpsの役割

DevOpsは「Dev(開発)チームとOps(運用)チームが協力してプロジェクトを進めていく」手法です。従来の開発プロジェクトではDevチームがアプリケーションを開発して、Opsチームがそれを受け取り、構築したインフラ上にデプロイするという流れでアプリケーションを利用できる状態にし、運用していたかと思います。これがDevOpsとなるとその役割はどのように変わるのでしょうか。

DevOpsの観点では、Devチームの役割が大きく変わるわけではありません。自動化の恩恵でやるべき作業自体は減少し、開発の速度は向上しますが、動くアプリケーションを開発するという役割は同じです。ただし、Devチームが今までGitによるバージョン管理やテストコードの作成を蔑ろにしてきた場合は、これを適切に実行する必要があります。今まで手動で行ってきた部分を自動化するためには、これらの取り組みは欠かせません。

一方、Opsチームは従来のアプリケーションの稼働環境のみではなく、開発におけるCI/CD環境の構築と運用もその役割となります。CI/CD環境は安定した運用を目指すアプリケーションの稼働環境とは異なり、効率的に開発プロセスが進むように構築、改善を行っていく必要があります。

DevOpsインフラを実現するためのエンジニア

Opsチームの役割が広がることで、Opsチームのエンジニアには新しい知識が求められます。CI/CD環境を構築するための知識は、従来のアプリケーションの稼働環境を構築する知識とは異なり、開発プロセスの自動化が主なものとなります。そのためにはCI/CDを実現する様々なツールやGitリポジトリといった新しい技術を習得する必要がありますし、インフラの構築方法もIaC(Infrastructure as Code)といった手法を習得する必要があります。さらに、これらの技術や手法を用いて環境を構築するだけでなく、Devチームと協力してより良い開発ができるように改善する必要もあります。

プロジェクトでDevOpsを実現するためにはこれらの知識を持ったエンジニアが必要となるため、これらのスキルを持つ人材を育成するか獲得しなくてはいけません。とはいえ、人材不足が叫ばれる昨今ですし、人材の育成にも時間がかかってしまい、なかなかDevOpsを実践できないということも珍しくありません。そのような場合は、外部の助けを借りることも解決方法の1つです。

どのような開発プロセスにするのか

では、CI/CDを構築できるエンジアがいればDevOpsを始められるのか、と言えば、そうではありません。CI/CDの主な役割は開発プロセスの自動化です。CI/CDを構築するためには、どのような開発プロセスにするのか、どこを自動化の対象とするのかを明確にする必要があります。

図2：DevOpsにおける開発プロセスの例

開発プロセスを明確にしよう

ところで「開発プロセスを明確にする」とは、どういうことでしょうか。開発プロセスを決めると言うと、アジャイル開発でScrumを採用するといったことが思い浮かぶかもしれません。しかし、自動化をターゲットとした場合、さらに詳細な開発プロセスを定義しなければなりません。

例えば、TDD(Test Driven Development)を前提としてどのタイミングでテストを実施するか、Gitのブランチ戦略に何を選択するのか、何をトリガーにどの環境にデプロイするかといったことを検討し、CI/CDでどのような処理を実行させるかを決定する必要があります。また、テストやデプロイが失敗した場合に、開発者へどのようなフィードバックを届けるのかといった例外系のプロセスもCI/CDで実行するように設計しなければなりません。従来は人がその場その場で判断して行っていたようなプロセスも、CI/CDで自動化するにあたっては明確に定義する必要があります。

これらの開発プロセスの定義は、プロジェクトのかなり早い段階で定義しておく必要があります。というのもCI/CDのプロセスをプロジェクトの途中から導入するのは容易ではなく、アプリケーション開発の初日から回るようにしておくことが望ましいからです。加えて、一度決めた開発プロセスを延々と維持するのではなく、改善し続けることも重要です。早い段階で決めた開発プロセスがそのプロジェクトにフィットするかは実際に開発プロセスを回してみないとわかりません。また、フィットしていたとしても改善点が全くないということも稀です。そのため、開発プロセスも定期的に見直しできるような仕組みを導入することが望ましいです。

テストはどこまで行うのか

CI/CDにおける開発プロセスでどこまで自動化するか、で議論になるのが、どのテストを自動化して、どのテストを手動で行うかの判断です。ソースコードレベルを意識したホワイトボックステストとなる単体テストを自動化するのは一般的ですが、ブラックスボックステストとなるE2Eテストに関してはUIの操作と検証の自動化が必要となり、自動化の難易度が高いため手動で行うプロジェクトも少なくありません。しかし、E2Eテストが自動化できれば開発効率における効果が非常に高く、自動化の対象とするかの判断は難しいところです。

また、昨今ではセキュリティテストを自動化するケースも増えてきています。皆さんも「DevSecOps」というキーワードを耳にしたこともあるかと思いますが、まさにDevSecOpsはセキュリティテストを自動化しようという概念です。

セキュリティテストには、SCA(Software Composition Analysis)といったパッケージやライブラリの脆弱性診断、SAST(Static Application Security Test)といったコードレベルでの脆弱性診断、DAST(Dynamic Application Security Test)といった稼働状態のアプリケーションの診断などのテストがあり、ひと言でDevSecOpsと言っても、どこまでを自動化の対象とするかは議論が必要です。SCA、SASTは比較的自動化が容易なためDevSecOpsの導入において適用されることが多いですが、DASTはE2Eテスト同様に自動化の難易度が高く、適用が難しいセキュリティテストです。

このほかにも、負荷テストを自動化するかといった議論もあり、自動化をして繰り返しテストを行うことで効率的に品質を上げるという点と、テストを自動化することへの技術的難易度とのトレードオフを検討する必要があります。

どのようなリリース形態にするのか

DevOpsの特徴の1つに「頻繁にリリースする」というプラクティスがあります。このリリースをするという点を本番環境へのリリースと捉えると、「そんなに頻繁に本番環境を変更しないからDevOpsを採用しない」という意見も出てきます。実際、DevOpsの初期の事例では本番環境へのリリースを頻繁に行う事例が紹介されていました。

ただし、CI/CDの観点では必ずしも本番環境へのリリースをゴールとはしていません。実はCI/CDのCDには「Continuous Delivery(継続的デリバリー)」と「Continuous Deployment(継続的デプロイメント)」の2つの意味があります。それぞれどこをゴールとするかは異なるため、アプリケーションのリリースをどこまで自動化するかを検討する必要があります。

図3：継続的デリバリーと継続的デプロイメント

継続的デリバリー

継続的デリバリーでは、自動化のゴールをリリース可能な状態への準備と位置付けます。高頻度で本番環境へのリリースを行わない場合や、本番環境へのリリース前に人によるチェックが必要な場合などは、継続的デリバリーで本番環境へのリリース直前までを自動化するようにします。

具体的な例としては、コンテナ環境であればコンテナリポジトリに登録するまでだったり、モバイルアプリであれば配信環境にアップロードするまでなどの方法が考えられます。

ただし、本番環境へのリリース自体を手作業で行うのは得策ではありません。継続的デリバリーにおいてはリリース前に人による検証作業が入るだけで、本番環境へのリリースは人的ミスを排除する観点で機械的に行なうことが望ましいです。

継続的デプロイメント

一方、継続的デプロイメントでは、本番環境へのリリースまでを自動化します。SaaSのようにアプリケーションの改善をいち早くサービスに取り込むことで、継続的サービスに対する満足度の向上を実現する場合などは、継続的デプロイメントを採用します。

継続的デプロイメントにおいては、継続的デリバリーとは異なり人による検証作業が入らないため、自動化されたプロセスの中でその作業を行う必要があります。具体的には、アプリケーションに対するブラックボックステストを行うようなE2Eテストなどが挙げられます。また、検証作業を自動化したからと言って、リリースされたアプリケーションに問題がないという保証はできません。そのため、全ての環境に一気にリリースをするのではなく、部分的に新しいリリースを行うブルーグリーンデプロイメントやカナリアリリースなどのリリース方法も検討する必要があります。

おわりに

今回はプロジェクト運営の視点から、DevOpsを始めるにあたって具体的に考慮すべきことを解説しました。次回以降はインフラエンジニアの立場でOpsの役割として、開発者の立場でDevの役割として、DevOpsを始めるにあたっての具体的に何を考慮すべきかを、弊社のそれぞれの分野の担当エンジニアから紹介します。