ALM Advent Calendar 2012 開発と運用を繋ぐために ~DevOpsを考える~

ALM Advent Calendar 2012 #TFSUG : ATND ラストのエントリです。

@kaji_3 こと、かじです。SIerでエンジニアしてます。

ALM Advent Calendar のラストです。TFS ではなくALM Advent Calendar となった事で幅広いエントリになり、大変勉強になりました。自分としてはネタを出しきったので来年に向けて研鑽していきます。今日は、ALM と一緒に語られる事が多い DevOps について考えている事をまとめます。

コンテキスト

  • 受託開発
  • エンタープライズ
  • 継続的デリバリーが出来ていない現場

DevOps と 成果物請負受託開発 & 運用

DevOpsは「Develop」=「アイデア→動くソフトウェア」、「Operation」=「インシデント→解決策」という2つの作業を顧客価値向上のためコラボレーションする事です。詳細はALMってなに?をご参照ください。
DevOps という言葉は「顧客ビジネスの価値向上」をゴールとしていれば自然と辿り着く気がしますが、成果物請負型開発は顧客ビジネスの価値向上がゴールではないためSIerへの浸透は時間がかかる気がします。(ちなみに、顧客のビジネス価値向上=対価安くする事、ただ働きと考えている人は頭冷やしてください。)

Operation を考慮しなければ詰む

DevOpsの浸透に時間がかかるとは言え運用を考えずに開発すれば、インシデント対応時の調査に不都合が発生し顧客と運用担当者から指摘がきます。指摘によっては自社の評価が悪くなり継続的に仕事を頂けず自社の価値が減ります。なので、「運用のしやすさ」を考慮するのは当然だと思うのですが。。

開発時になんで運用の事を考えられないか

「運用の事を考慮して」は当然の事なのですが出来ていない現場をちょくちょく見ます。非機能要件の定義不足、運用要件の定義不足、タイトなスケジュールによる実装対象から外れたなどが直接的な原因ですが、根本は「運用した事がないから」ではないかと考えてます。経験があれば情報収集に困るアプリケーションは作りたくないと考えるはずですが、必要とされるスキルと知識が異なるため開発チームに所属する人は運用経験がない場合がよくあります。そんな人に運用を意識してもらうために幾つかやっていた事をあげてみます。

開発チームでやっていた事

保守開発では運用チームから人を引っ張ってくる

機能拡張の時に現在システムを運用している人に設計、テスト設計のレビューをして貰いました。運用時に考慮しなくてはいけない事は設計時に盛り込みますが、システムの癖(顧客がよくチェックする箇所、システムエラーが発生しやすい箇所など)に対応するため運用の方の知識は重要でした。

動作確認環境を使い不具合調査シミュレーション

ログ出力レベルなどの設定を運用時と同一のテスト用環境を構築し、画面間の遷移や機能間の連携のテストを実施しました。そこでシステムエラーなどが発生し、調査しずらい箇所については課題管理してログ出力レベルの見直し等を実施しました。

本当にやりたかった事

保守運用時も開発時と同じツールを使う

開発時、顧客の受入テスト以降は受入テストが運用と考えるとDevOpsの模擬練習のようなもので、顧客のフィードバックをシステムに適切に反映していると思います。ここで学んだリズムがツールによって支えられている場合、例えば、チケット管理でバックログ、バグを管理→バージョン管理にチケット番号を反映してリリース管理となっているとこのツールを使ったよいサイクルはツールがなくなると崩れてしまいます。しかし、運用になると顧客環境でチケット管理(インシデント管理)される事が多いためこの旨いサイクルが崩れてしまいます。開発時に使っている環境をそのまま顧客環境で再現するもの手ですが、他社との連携が難しくなります。そのため、ローカルな環境にツールを準備するのはDevOpsを考慮するとよろしくないはずです。Team Foundation Service は私の考えている同じツールを使うという所に見事にマッチしていると思います。クラウド上でデータを管理するため顧客との調整は必要と思いますが、システムの特性によっては可能と思います。

そんな理由で来年はTeam Foundation Service を業務で利用したいのですがセキュリティとか考えなくてはいけない事が多いのでどなたか事例を教えて頂けると幸いです!!