SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

【デブサミ2015】セッションレポート(AD)

【デブサミ2015】20-B-2 レポート
「DevOps」やってみた、そして、気づいたこと・陥ること・見直すところ

  • X ポスト
  • このエントリーをはてなブックマークに追加

 DevOpsは特定の規格ではないため、その解釈、やり方、向かう所など、皆同じではない。とはいえ、それぞれが何かの課題を解決しよう、開発と運用の現場をより良くしようという「思い」から始まっているのは同じだ。本セッションでは、そんな思いからそれぞれが考えたDevOpsを「やってみた」現場から、「気づいたこと」や「陥ってしまったこと」を振り返ると共に、「見直すべきポイント」をIBM DevOpsソリューションを切り口に解説された。

  • X ポスト
  • このエントリーをはてなブックマークに追加

日本アイ・ビー・エム株式会社 IBM システムズ・ソフトウェア事業部 テクニカルセールス統括部
アプリケーションデベロップメント・テクニカルセールス シニアITスペシャリスト 川瀬 敦史氏
日本アイ・ビー・エム株式会社 IBM システムズ・ソフトウェア事業部 テクニカルセールス統括部 アプリケーションデベロップメント・テクニカルセールス シニアITスペシャリスト 川瀬 敦史氏

DevOpsで誰もが考える自動化の前に、標準化が必須

 川瀬氏が考えるDevOpsの概念の基本は「Keep on developing」、「Keep on operating」つまり「創り続け、生かし続ける」ということだ。

 川瀬氏が最初に「DevOpsをやってみたら」の事例として紹介したのは、小さな組織で小さく始めようとしたケースだ。業務はWebサービスの開発で、10人程度のメンバーが開発から運用まで頑張っている。明文化されたルールはなく、暗黙のルールによりどうにか回っていた。

 ただ、ビジネスの拡大、拡張により今のままではいずれ不具合が生じる可能性が高まってきたため、上層部が「DevOpsをしてみよう」と考え、進めることとなった。

「やった」規模は?
「やった」規模は?

 最初にやったことは、テスト、デプロイなどの自動化の検討だ。現場では、これなら簡単で、すぐに効果がありそうだと考えた。それに対し、IT経験の長い上層部から「部分最適ではなく、全体最適をやってみたら」とアドバイスがあった。確かに自動化は即効性があり、効果がある。ただ部分最適だけやっても後々問題が生じないのか、と。きちんと最初に現状を確認しておいて、そこから最終形を描き、自動化や、できていないところをやるべきではということで、全体最適から行おうという流れになった。

 そこでまずやるべきことが二つある。

 一つは、デプロイの仕組みの再構築だ。時代の流れに沿ってオンプレミスからクラウドへ移行し、それを見据えてデプロイの標準化、自動化を行っていく。既存のデプロイプロセスを見直し、全アプリ/全環境共通のデプロイフレームワークを策定する。

 もう一つは、ソフトウェア構成管理の見直しだ。デプロイについて検討するなか、ソース管理が個人管理で、前工程がぐだぐだであるという課題が見えてきた。そこでデプロイフレームワークに対応するソフトウェア構成管理を見直した。ソフトウェア構成管理計画を策定し、デプロイ単位でのファイル管理や、並行開発、作業との関連づけなどを行った。

 そのために導入されたのが「IBM UrbanCode Deploy」になる。デプロイ作業自動化の手助けをしてくれるもので、そこで求められる作業が機能として提供されている。まずデプロイ手順を見える化し、どのコンポーネントにどのバージョンが入っているかを俯瞰できるようにする。テストが終わったら、ドラッグ&ドロップで、次の環境をスケジューリングすることもできる。

 また最近は、複数のモジュール、機能を、時にはサーバーをまたがり、同時進行で開発することも多い。その作業状況と連携し、確認できるアプリ、要件からテストなど先に進めておくケースのため、影響を見える化できるようになっている。さらにアプリケーション環境の作成およびプロビジョニングも可能だ。

 さて今回のケースで「やってみた」結果「陥ったことは以下の通りだ。

  • コスト、期間が想定以上にかかった。
    • 「やる」は人数/規模に正比例しない
  • 思った以上に「やる」ことが多い
  • 小さくても「やる」範囲は広い

 川瀬氏が紹介した二つ目の事例は、継続的インテグレーション(CI)を進めてみた大手企業の話になる。関連組織も大きく、開発部門、運用部門に加えて基盤部門、標準化部門、PMOがある。その中で、標準化部門の施策としてDevOpsを推進することになり、「生産性をあげるにはCIが良いらしい」ということから、まずCIの標準環境を決めて、準備を開始した。

 「やってみた」ことでは、各チームにソース管理用サーバーを用意し、全体では共通ビルド用サーバーを数台用意した。開発部門はサーバーにソースを入れると、自動的にビルドしてくれるという段取りになる。

 ところが、開発チームごとにソース管理のやり方がバラバラだったので、共通のビルドの仕組みにはなかなか乗せられない。そもそもビルドとその前後の標準化ができていなかった。そのためバイナリが肥大化し、ビルド時間が日に日に増加していった。またJavaの管理規約もバラバラなので、ソース管理からのファイル取得、ビルドの手順もバラバラという結果になった。

 さらに「陥ったこと」として、運用部門が用意した共通ビルドサーバーのスペックが足りず、チームごとのビルドサーバーをばらまく結果となってしまった。開発部門はビルド担当者をアサインせざるを得ず、さらに日々のファイル管理がとても面倒になった。

 ここで「気づいたこと」、「見直すべきこと」だが、開発や運用を知らずに標準化をやろうとする人たちは、コスト以外にも気にすべき点があることを知っておくべきだ。将来的な理想像で検討するのではなく、きちんと現状の課題を把握してから「何が必要なのか、どう進めればいいのか」を考えることが重要になる。

 ここでもやはり、ソフトウェア構成管理の見直しが必要になる。ポイントは最終的なビルドを意識したファイル/ディレクトリの構成、個人ビルド、統合ビルドのルール決めだ。

次のページ
何を自動化するか厳選し、テストは可能なものから先行する

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
【デブサミ2015】セッションレポート連載記事一覧

もっと読む

この記事の著者

CodeZine編集部(コードジンヘンシュウブ)

CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/8558 2015/04/08 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング