(Photo by：Brad Montgomery)
このような方におススメ
- DevOpsと開発者の位置づけを整理したい。
- プログラミングとDevOpsの関係性を見直したい。
開発と運用と品質保証が三位一体となって１つのサービス・プロダクトを提供する体制がDevOpsです。開発者（プログラマ）に求められるのは名前の通り「開発」ですが、従来と異なり運用と品質保証の二部門と密接なコミュニケーションを取りながら開発を継続します。この記事ではDevOpsを意識した開発者に求められる事柄を説明して行きます。
プログラマが知る必要があるスキル
開発者、運用、品質管理でそれぞれ利用するツールが異なります。例えば開発者はCIツールの構成やそのメンテナンス方法を知らない事が多いと思います。Dockerなど仮想環境も開発環境として利用しない場合もあります。
運用や品質管理もプログラマが利用しているツールを全て把握している訳ではありません。
DevOpsで扱われるツール・スキルは多岐にわたることが多いため、全てを知る必要はないと思います。その中で強いて必要とされるスキルがあるとすれば「テスト自動化」に関するスキルと「CIツール内でのテスト」に関する理解の2つです。
品質管理を効率的に行うにはリグレッションテストが必要不可欠です。そのテストを定期的に実行するCIツールも欠かせないものです。
開発者としてテストをパスする事はもちろんですが、書いたテストコードが「自分が開発している環境とは異なる環境で動作し」「何千、何万と繰り返し実行される」この２つの事の理解が求められます。
これは受け入れテストをパスすれば書いたソースコードが納品となり開発者の手元から離れるとウォーターフォール型開発で行われていた習慣とまったく異なるものです。
開発規模が大きくなるとテストコードの実行速度も求められますし、変更・改修・機能追加が繰り返されるにつれ今まで動いていたコードが動かなくなる事がまま起こります。
開発したソフトウェアは開発時とは違う環境で動作する事が殆どだと思います。OS・依存するライブラリ・実行環境のバージョンアップなど長く使われるソフトウェアは同じ環境で動作し続ける事の方が少なく、新しい環境に追従するために定期的なメンテナンスを行う必要があります。
毎回ゼロからテストをやり直していたのでは開発コストが高くなるため、リグレッションテストを実現するためのテストコードが必要になり、このテストコードを書くには「異なる環境で」「繰り返し実行される」という2つの性質を理解が求められます。そのためテスト自動化とCIツールに対する一定の理解が必要になります。
コードレビューとツールのカバー範囲の違い
CIツールを使ったリグレッションテスト以外のソフトウェアの品質保証としてコードレビューがあります。同じくコードを解析してバグの検出や警告を出す静的解析ツールがあります。
静的解析ツールを利用すればコードレビューが必要なくなるかという考え方もありますが、コードレビューと静的解析ツールでは得意とする領域が異なるためどちらか片方のみという訳には行きません。
静的解析ツールは人間が見つけづらい規約に沿っていない箇所や問題となるパターンを検出してくれます。コードレビューは論理的に正しいのかの判断や、プロジェクト内での依存関係から今見ているコードが他コードに影響して問題が起こるか等の全体を見ての問題検出が可能です。
そのためどちらか片方という性質ではなく、両方の実施が求められます。
コミュニケーションで解決する問題
DevOpsでは他部門や他領域を専門とするエンジニアと密なコミュニケーションが求められます。コミュニケーションで解決する問題としては、お互いに気づいていない潜在的なリスクの共有があります。
(Photo by：Iwan Gabovitch)
専門領域がそれぞれ異なるため、お互いに知っていることがある中で片方しか知らない事もあります。コミュニケーションを取る中で、自分の開発したものがどのように運用されるか想像できるようになります。
運用している中で不具合が起こりそうな部分やパフォーマンス障害になりそうな箇所を事前に運用側へ伝える、相談する、検証することでリスクの先払いができます。
知っていることを事前に伝えない、決定している要望を相手に伝えないと言った事が繰り返されると、信頼関係が崩壊します。
同じ企業内での開発であればそれでも暫くはプロジェクトを続けていられますが、もし企業をまたいでのプロジェクトでこのような事が行われると企業単位でチームの離脱、最悪のケースとして努力義務に怠りがあり不利益が発生したとして訴訟になる場合があります。
コミュニケーションには信頼関係を作る効果もあるため、それぞれお互いを尊重してコミュニケーションを取るとリスクを軽減する事ができます。
リスクが格段に高まるのが片方からコミュニケーションを一方的に遮断した場合です。この場合はプロジェクト内で早急に解決する必要があります。
そのバグはだれのせいか？
ソフトウェアには大小問わずバグが必ず発生します。バグの発生を小さく抑えてリスクを先払いするのがDevOpsで実現するプロジェクト体制です。開発・運用・品質保証と連携が取れていれば、バグは管理されるものであって誰のせいでもありません。
部屋を掃除するときに、このホコリは誰の机の下から出たから誰が悪いなんて話にはならないと思います。バグについても同じで必ず発生するため、いかに管理して小さく抑えるかが肝要です。
まとめ・要約
ソフトウェアの利用者に高い品質・サービスを提供するための体制がDevOpsです。その中で開発者（プログラマ）に求められる役割も従来とは少し異なってきますので、DevOpsを検討する際の参考の１つになれば幸いです。
本ブログは、Git / Subversionのクラウド型ホスティングサービス「tracpath(トラックパス)」を提供している株式会社オープングルーヴが運営しています。
エンタープライズ向け Git / Subversion 導入や DevOps による開発の効率化を検討している法人様必見！
「tracpath(トラックパス)」は、企業内の情報システム部門や、ソフトウェア開発・アプリケーション開発チームに対して、開発の効率化を支援し、品質向上を実現します。
さらに、システム運用の効率化・自動化支援サービスも提供しています。
”つくる情熱を支えるサービス”を提供し、まるで専属のインフラエンジニアのように、あなたのチームを支えていきます。
No Comments