概要

本記事において、近年の日本国内に置ける開発手法の遷移とそれによって発生した課題について確認し、DevOpsとは何かを「ざっくり」と確認していきたい。

詳細

1. 開発手法の遷移

世間で使用される開発手法は「Waterfall」から「Agile」へ遷移している。（これは「どちらの開発手法が優れているのか」という話では決してない） *1

（「Waterfall」と「Agile」の詳細については、記事が肥大化を防ぐため割愛する。）

そして、本記事で解説していく一般的に「DevOps」と言われている文化はこの開発手法の遷移によって発生した（または肥大化した）課題を解決するため生まれた。

2. 残された課題

「Waterfall」開発に比べ、「Agile」開発においては頻繁にソフトウェアがアップデートされ、運用への引き渡しが何度も行われることとなる。

このような頻繁なアップデートが行われると以下のような課題が発生する。

• 長期に渡り、頻繁にソフトウェアのアップデートが行われる場合。ハードウェアのアップデートタイミングやその可否について、ソフトウェアに与えるインパクトを運用サイドが把握できず、結果としてハードウェアに技術的負債を抱えたまま運用しなければならない状況になる。

• ソフトウェアに対し、インフラストラクチャの変更が必要な大幅なアップデートが行われる場合、インフラストラクチャの追加や変更に関して「開発」サイドと「運用」サイド間のオーバヘッドが生まれ作業に遅れが生じる。

3. DevOpsの発展とプラクティス

これらの課題を解決するため、DevOpsという文化は生まれ、発展してきた。

また、具体的なアクションとして、DevOpsには以下ようなのプラクティスが存在する。

• Infrastructure as Code (IaC)
• Continuous Integration (CI)
• Continuous Delivery / Deployment (CD) *2

しかしながら、開発サイドと運用サイドが分かれていることによる情報伝達のオーバーヘッド等を課題の根本だと考えた場合、プラクティスを適用するだけでは完全な解決にはならず、「Agile」開発に則した組織を作っていく必要がある。

この根本原因の解決方法としてDevOpsには「Cross Functional Team」というものが存在する。名前のとおり、開発サイドと運用サイドを分けずに1つのチームとしてプロジェクトを運用することである。また、チーム内で密なコミュニケーションを取れるようにツールや個人の動きや発生した課題を把握できるようにする。

ここからはDevOpsの具体的なイメージするため、本項の最初に述べたプラクティスについて簡単に解説していく。

Infrastructure as Code (IaC)

ソフトウェアの開発においてソフトウェア自体のバージョンの管理はソースコード上であったり、バージョン管理サービスを使用することが通例となっている。

このIaCと呼ばれるプラクティスはソフトウェアだけでなくインフラストラクチャに対しても同じようなバージョン管理の概念の導入する考えであり、コードとしてブートストラッピングからコンフィグレーション、オーケストレーションの領域を管理する。

メリットとして下記が挙げられる。

• プロビジョニングに必要な全ての要素を可視化することによるインフラストラクチャの透明性が確保される。
• 構成管理サービスやツールを使用することでプロビジョニング時の属人性が排除される。

Continuous Integration (CI)

日本語で継続的インテグレーションと呼ばれている。ソースコードのアップデートやビルド、テストを頻繁に行っていくことである。またそれらの作業の自動化が含まれる。

メリットとして下記が挙げられる。

• コード内に潜むバグの早期発見が可能となる。
• 自動化による作業コストの削減が可能となる。
• ソースコードの透明性の確保される。
  • これは自動化を行う上で、必然的に一箇所に最新のテストの完了したソースコードが存在することになるため。

Continuous Delivery / Deployment (CD)

これは上記CIの要素に加え、インフラストラクチャへのデプロイまでを部分的に自動化（または完全に自動化）する。

メリットとして上記CIのメリットに加え、下記が挙げられる。

• デプロイメントを自動化することにより、手動による過失を防ぎ、デプロイされたソフトウェアの透明性を確保する。（Continuous Deliveryにおいては手動となる部分が最小限となるようにすることが理想となる。）

プラクティスへのアプローチ

これらのプラクティスを弊社では以下のツールやサービスを活用し、現場で運用している。

• Infrastructure as Code (IaC)
  • Ansible
• Continuous Integration (CI)
  • GitHub
  • Jenkins
  • Azure DevOps
  • AWS CodePipeline
• Continuous Delivery / Deployment (CD) *
  • 上記CIで述べたツールに加え
  • Azure Container Registory (ACR)
  • Azure Kubernetes Service (AKS)
  • AWS ECR
  • Amazon EKS

まとめ

DevOpsという文化が注目され始めたのは、日本国内で開発手法が「Waterfall」から「Agile」へ遷移したことが原因だと考えて良いだろう。

しかし、「Waterfall」開発がメインで採用されていた頃からDevOpsのプラクティスは部分的に存在し、適用されていた。（Jenkinsによる自動テストや自動デプロイなどは多くの現場で採用されていた。インフラのバージョン管理も同様である。）

もし、プロジェクトへAgile開発を導入する場合、マネジメントを行う立場としてDevOpsプラクティスを導入するだけでなく、組織レベルで体制を見直すべきだろう。

補足

• *1: https://techbeacon.com/app-dev-testing/survey-agile-new-norm
• *2: 日本において、CDというと前者が取り上げられることが多い。環境へのデプロイが手動であるか自動であるかの違いがある。