アプリケーションデベロップメント・テクニカルセールス シニアITスペシャリスト 川瀬 敦史氏
DevOpsで誰もが考える自動化の前に、標準化が必須
川瀬氏が考えるDevOpsの概念の基本は「Keep on developing」、「Keep on operating」つまり「創り続け、生かし続ける」ということだ。
川瀬氏が最初に「DevOpsをやってみたら」の事例として紹介したのは、小さな組織で小さく始めようとしたケースだ。業務はWebサービスの開発で、10人程度のメンバーが開発から運用まで頑張っている。明文化されたルールはなく、暗黙のルールによりどうにか回っていた。
ただ、ビジネスの拡大、拡張により今のままではいずれ不具合が生じる可能性が高まってきたため、上層部が「DevOpsをしてみよう」と考え、進めることとなった。
最初にやったことは、テスト、デプロイなどの自動化の検討だ。現場では、これなら簡単で、すぐに効果がありそうだと考えた。それに対し、IT経験の長い上層部から「部分最適ではなく、全体最適をやってみたら」とアドバイスがあった。確かに自動化は即効性があり、効果がある。ただ部分最適だけやっても後々問題が生じないのか、と。きちんと最初に現状を確認しておいて、そこから最終形を描き、自動化や、できていないところをやるべきではということで、全体最適から行おうという流れになった。
そこでまずやるべきことが二つある。
一つは、デプロイの仕組みの再構築だ。時代の流れに沿ってオンプレミスからクラウドへ移行し、それを見据えてデプロイの標準化、自動化を行っていく。既存のデプロイプロセスを見直し、全アプリ／全環境共通のデプロイフレームワークを策定する。
もう一つは、ソフトウェア構成管理の見直しだ。デプロイについて検討するなか、ソース管理が個人管理で、前工程がぐだぐだであるという課題が見えてきた。そこでデプロイフレームワークに対応するソフトウェア構成管理を見直した。ソフトウェア構成管理計画を策定し、デプロイ単位でのファイル管理や、並行開発、作業との関連づけなどを行った。
そのために導入されたのが「IBM UrbanCode Deploy」になる。デプロイ作業自動化の手助けをしてくれるもので、そこで求められる作業が機能として提供されている。まずデプロイ手順を見える化し、どのコンポーネントにどのバージョンが入っているかを俯瞰できるようにする。テストが終わったら、ドラッグ＆ドロップで、次の環境をスケジューリングすることもできる。
また最近は、複数のモジュール、機能を、時にはサーバーをまたがり、同時進行で開発することも多い。その作業状況と連携し、確認できるアプリ、要件からテストなど先に進めておくケースのため、影響を見える化できるようになっている。さらにアプリケーション環境の作成およびプロビジョニングも可能だ。
さて今回のケースで「やってみた」結果「陥ったことは以下の通りだ。
-
コスト、期間が想定以上にかかった。
- 「やる」は人数／規模に正比例しない
- 思った以上に「やる」ことが多い
- 小さくても「やる」範囲は広い
川瀬氏が紹介した二つ目の事例は、継続的インテグレーション（CI）を進めてみた大手企業の話になる。関連組織も大きく、開発部門、運用部門に加えて基盤部門、標準化部門、PMOがある。その中で、標準化部門の施策としてDevOpsを推進することになり、「生産性をあげるにはCIが良いらしい」ということから、まずCIの標準環境を決めて、準備を開始した。
「やってみた」ことでは、各チームにソース管理用サーバーを用意し、全体では共通ビルド用サーバーを数台用意した。開発部門はサーバーにソースを入れると、自動的にビルドしてくれるという段取りになる。
ところが、開発チームごとにソース管理のやり方がバラバラだったので、共通のビルドの仕組みにはなかなか乗せられない。そもそもビルドとその前後の標準化ができていなかった。そのためバイナリが肥大化し、ビルド時間が日に日に増加していった。またJavaの管理規約もバラバラなので、ソース管理からのファイル取得、ビルドの手順もバラバラという結果になった。
さらに「陥ったこと」として、運用部門が用意した共通ビルドサーバーのスペックが足りず、チームごとのビルドサーバーをばらまく結果となってしまった。開発部門はビルド担当者をアサインせざるを得ず、さらに日々のファイル管理がとても面倒になった。
ここで「気づいたこと」、「見直すべきこと」だが、開発や運用を知らずに標準化をやろうとする人たちは、コスト以外にも気にすべき点があることを知っておくべきだ。将来的な理想像で検討するのではなく、きちんと現状の課題を把握してから「何が必要なのか、どう進めればいいのか」を考えることが重要になる。
ここでもやはり、ソフトウェア構成管理の見直しが必要になる。ポイントは最終的なビルドを意識したファイル／ディレクトリの構成、個人ビルド、統合ビルドのルール決めだ。
