#はじめに
ある日の昼下がり、先輩に呼び出された新入社員の私は、唐突にこう告げられたのだった。
先輩「うちの会社はDevOps と Infrastructure as Codeを導入してるから」
私「・・・・・・・・・・・・」

でぶおぷす？いんふらすとらくちゃあずこーど? ナニソレオイシイノ？
という状態になったので、今回はDevOpsとInfrastructure as Codeについて、新入社員の私でも理解できるくらいにかいつまんで説明しようと思う。

#対象読者

巷でDevOpsってものが流行っているけど、そもそもDevOpsって何なの？って人
会社でDevOpsが導入されているけど、どうして必要なのって人
Infrastracture as Codeとは？どんなメリットがあるの？って人

#構成

はじめに
対象読者
構成
そもそもDevOpsってなに？
開発のライフサイクル
開発チーム(Development)と運用チーム(Operations)のジレンマ
CI/CDについて
Infrastructure as Codeを用いることのメリット
さいごに

#そもそもDevOpsってなに？
Wikipediaによると

DevOps（デブオプス[1]）とは、ソフトウェア開発（Dev）と運用（Ops）を組み合わせた一連のプラクティスで、システム開発のライフサイクルを短縮し、ソフトウェア品質の高い継続的デリバリーを実現することを目的としている。
参照 : https://ja.wikipedia.org/wiki/DevOps

これだけだと分かり辛いため、掻い摘んで説明すると: 開発側と運用側が仲良く手を結んで、より良いシステムを迅速に、かつ継続的にエンドユーザーに届けられるようにしよう

ということである。

しかし開発未経験の私にとっては開発のライフサイクルそのものを理解していなかったため、復習も兼ねて説明しようと思う。

#開発のライフサイクル

開発 : 新サービスのコードを作成する
ビルド & テスト : 開発段階で作成したコードを機械語に翻訳して、テスト環境でテストを行う
デプロイ : 本番環境で新サービスを実施する
モニター : システムが正常に動作しているか監視する
プラン : モニターで得られたデータをもとに、次の開発に向けてプランを立てる

開発 → ビルドとテストを行う → 本番環境でデプロイ → モニターする → 次の開発に向けてプランを立てる → 開発 → ......

DevOpsにおいては、このサイクルを出来るだけ短い周期で行うことで、速いペースで製品の進歩と向上を達成し、エンドユーザーにサービスを提供することを目的としている。

#開発チーム(Development)と運用チーム(Operations)のジレンマ

開発チーム : システムに新しい機能を追加する
運用チーム : システムを安定して稼働させる

開発チームはシステムに新しい機能を追加して、ユーザーに新サービスを提供したいが、運用チームはシステムの安定的な稼働を目的としているため、出来るだけ変更を加えて欲しくない。
「エンドユーザーにより良いサービスを提供する」という共通目標があるにも関わらず、両チームのアプローチが相反するため、結果的に共通目標が達成できない場合がある。

そのため組織全体でプロジェクトの認識を共有、またプロジェクトを円滑に進めるためにも、DevOpsは必要である。

#CI/CDについて
DevOpsについて調べていくと、よく継続的インテグレーションや、継続的デリバリー、継続的デプロイメントという言葉を目にする。

Red Hatが公開しているWebサイトでは下記のように述べられている。

CI/CD (継続的インテグレーション/継続的デリバリー) とは、アプリケーション開発のステージに自動化を取り入れて、顧客にアプリケーションを提供する頻度を高める手法です。CI/CD から発生した主なコンセプトは、継続的インテグレーション、継続的デリバリー、継続的デプロイメントです。CI/CD は、新規コードの統合によって開発チームや運用チームに生じる問題 (すなわち「インテグレーション地獄」) に対する解決策です。
参照：Red Hat CI/CDとは

筆者の読解力が低いせいか、悲しいことに、なんのこっちゃかさっぱりな文言である。
上記の文を理解するために、下記のAWSのWebサイトから参照した図を見て頂きたい。

ソフトウェアがデプロイメントされるまでの流れ

参照：AWS 継続的インテグレーションとは？

図の語句説明
Sourse Control：開発ソースコードに変更を加え、開発環境にマージをする
Build：ソースコードを機械語に変更し、単体テストを行う
Staging：ステージング環境にデプロイを行う
Production：本番環境にデプロイを行う

文章で説明すると、

新機能を追加したい開発者は、まず変更したコードを開発環境にマージ(統合)する(Souce Control)。
そして変更されたコードに問題がないか単体テストを行う(Build)。
ステージ環境(本番環境にあげる前の環境)にデプロイする(Staging)
本番環境にデプロイを行う(Production)

上記のような流れでソフトウェアはデプロイされるのだが、CI/CDはこのフローを自動化することを目的としている。

そして継続的インテグレーションや継続的デリバリーは、このフローがどの工程まで自動化されているかによって、定義がなされる。

継続的インテグレーション(CI : Continuous Integration)
・ Source Control → Build までの工程を自動化する。
・開発者がコード変更をマージする頻度を高めることができ、迅速なアプリケーション開発が可能になる。
・自動でテストをしてくれるため、バグを素早く容易に修正することができる。

継続的デリバリー(CD : Continuous Delivery)
・ Source Control → Build → Staging までの工程を自動化する。
・本番環境にデプロイできるコードを常に保持しておくことで、運用チームはアプリケーションを本番環境に素早くデプロイすることができる。

継続的デプロイメント(CD : Continuous Deployment)
Source Control → Build → Staging → Production までの一連の工程を自動化する。
・素早く本番環境に新機能や変更をデプロイすることができる。
・本番環境にデプロイされる前に、手動のチェックがないため、入念に設計された自動化を活用する必要がある。

どの工程まで自動化するかは、プロジェクトの内容やチームの方針によっても変わるだろうが、CI/CDを取り入れることによって、
・アプリケーション開発を迅速に進めることができる
・自動化によって人為的ミスが減少することで、本番環境に安定的にデプロイできるため、運用面でも効果が得られる
などのメリットがある。

#Infrastructure as Codeを用いることのメリット
そもそもInfrastructure as Codeとは？
「インフラストラクチャをコードで管理する」
そのままですね。

では、Infrastructure as Code を導入することで、DevOpsにおいて、どのようなメリットがあるのだろうか？

Wikipediaによると

IaCはDevOpsのベスト・プラクティスを実現する重要な要素だろう。開発者はもっと構成の定義に参加するようになり、運用チームは、開発プロセスの初期段階で入ってくるようになる。IaCを活用するツールはサーバーの状態・構成を視覚化し、企業内のユーザーに視覚性を提供し、最終的に努力を最大限にするために、チームを結集することを目指している。
参照 : https://ja.wikipedia.org/wiki/Infrastructure_as_Code

つまり、Infrastructure as Code を導入すると、どのチームもプロジェクト全体を通して参加するようになるため、プロジェクト全体の連携が可能になるメリットがあるという。

また具体的なメリットとしては下記のようなものがある。

一度記述したコードを共有・再利用できる
大きなプロジェクトになると、同一の環境をいくつも構築する必要が出てくる。
インフラをコードで管理すれば、コーディングによってループさせることで、手作業による手間を省くことができる。

人為的ミスが減少する
コードに記述されている通りに、インフラストラクチャが構築されていくため、大量にインフラの環境を整備しても、人為的ミスが起こらない。

ソフトウェア開発と同じ手法でバージョン管理を行える
履歴を残すことができるため、不備があった場合に以前の状態に戻すことができる。
上記で述べた CI/CD を用いることで、迅速にかつ安定的にインフラ環境を構築できる。

冪等性(べきとうせい)によって、常に同じ環境を構築できる
冪等性とは「同じ操作を何度繰り返しても、同じ結果が得られる」というもの。
どのような状態のインスタンスであっても、インフラ構築のコードを実行すれば、常に同じシステムが構築されるため、管理が楽である。

Infrastructure as Codeの詳細は下記のサイトを参照
Infrastructure as Codeの留意点とメリット　～サーバー更改プロジェクトへの適用で得られた知見・実感
 サーバーのカスタマイズはお手の物？！～構成管理ツール～

#さいごに
以上がDevOpsとInfrastructure as Codeについての解説である。
本記事の作成に当たって両者の理解度が深まったので、ようやく先輩にも安心して顔を合わせることができそう。