DevOpsについて～現場で起こっている問題～

お疲れ様です。伊藤です。

この度グループ会社内で、Ansible関連の説明会を行うことになりました。で、うちのグループなんですが基本的にシステム開発者メインで、インフラ技術者があまりいらっしゃいませんのでシステム開発者にも興味のある内容を、ということでDevOpsに絡めて説明を行います。

というわけでこちらでもちょっとDevOpsについてまとめておこうと思います。
そもそもDevOpsとは？というところからですが、ウィキペディアによると以下の通りになります。

DevOps（デブオプス）は、ソフトウェア開発手法の一つ。開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する（さらに両担当者の境目もあいまいにする）開発手法をさす。厳密な定義は存在しておらず、抽象的な概念に留まっている。ソフトウェアのビルド、テスト、そしてリリースの文化と環境を以前よりも迅速に、頻繁に、確実に発生する確立を目指している。 また、DevOpsにビジネス部門を追加したBizDevOpsというワードも広がりつつある。

あまり明確な定義はなさそうですが、「システム開発者とインフラ技術者の垣根をなくす」という意味だと認識しております。もうちょっと具体的に言うと、開発者がシステムの設定変更（ユーザ追加したり、環境変数変えたり）なんかも行う、という感じかと思います。
（インフラ技術者は環境の構築やその後の保守運用を行いますが、Operationとは保守運用部分のことを言っています）

今までのシステム開発の現場によくある構図は下記のような形だと思います。まあいろいろな理由があって大体仲が悪いです（笑）

DevOpsだとこうなる！

ではなぜそんなことが謡われているか、というところになるかと思います。そのあたりを私の主観満載で今までの経験をもとに感じたことをまとめておきます。

基本的にシステムの開発環境はテスト環境、本番環境に分かれます。まあ、現場によってはステージング環境とか検証環境とか色々ありますが、通常の現場で行くとテストと本番は必ず分かれてるかなと。
で、これも現場によって違うのですが、大体はテスト環境はインフラ技術者が初期構築を行った後は、開発者側で設定変更を行うことが多いです。なぜなら開発の段階で追加の環境変数が必要だったり、テストを行うためにユーザを増やしたり、ということをいちいちインフラチームにお願いしていたら開発も遅れるし、双方の手間になるので。

ところが本番環境の構築時には設定変更は大体が、インフラ技術者が行うことになります。そうするとテスト環境で行った設定変更が漏れる、ということが発生します。

こういった問題(もちろんこれだけではないですが)をなくすために、システム開発者が本番環境の設定変更やその後の環境管理も行う、というのがDevOpsが求められている理由だと思っています。それを実現するためにAnsibleやDockerの技術が利用できますが、そちらについてはまた別の記事で記述したいと思います。

それではお疲れ様でした。