ワンクリックデプロイ勉強会に参加してきた #ocdeploy

勉強会 CI 継続的デリバリー


(写真：講演終盤、ワンクリックデプロイを実演中の@Ryuzee氏。)

開催までの経緯

まずはこちらのつぶやきやり取りを。

…という様な感じでつぶやきのやり取りがなされ、この日に晴れて『ワンクリックデプロイ勉強会』が開催されました。

開催場所は日本マイクロソフト品川本社。私自身この日が2回目のマイクロソフト本社での勉強会だったのですが、開始前のモニターには何とTV画面が。勉強会とは関係無いところでちょっとした驚きでした(笑)


イベント発起人であるkatzchang(TwitterID:@katzchang)さんによる前説的トーク、会場をご提供頂いたTomoharu Nagasawa(TwitterID:@tomohn)さんの会場利用に関する諸々説明等を踏まえつつ、本編の講演開始です。

90分で分かるデプロイ自動化への道 改め『ワンクリックデプロイ 101』


既にスライド資料が上がっておりますので、詳細内容についてはスライド御参照下さい。こちらのエントリはざっくりメモ＆参照情報の展開程度に留めておきます。

また、今回の勉強会に先立ち、予習的エントリとして@Ryuzeeさんのブログにて以下の記事がUP・紹介されておりましたのでこちらでもご紹介。


  • (自動化は)一日にしてならず。
  • No Silver Bullet /『銀の弾丸は無い』。
    • 皆さんが現場のコンテキストに合わせてやるしかない。
    • 自分たちのプロセスは自分たちで進化させるしかない。
1.ビジネスを取り巻く環境の変化
  • IT投資は業務効率化から戦略実現へ
    • 以前の競争：ウサギと亀の競争
    • 現在の競争：不安定、変わりやすい高速の変化に対応しなければならない。
  • ※ビジネスの迅速な意志決定が必要。そして意志決定を元に素早く具現化する必要がある。
  • ビジネスモデルの賞味期限が短縮→1個のビジネスモデルで食える期間は短くなっている。

  • 事前に綿密に計画を立てて長期間遵守という形の維持難しくなってきている。
  • 変化が起こることを前提に頻繁に軌道修正することが必要。
  • 変化に対応出来なければマーケットから見捨てられる。そして価値が無くなれば滅びる(買収される)。

2.継続的デリバリ
  • 現在海外で本出ています。本読んだ人？→居なかった。

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))

  • 毎日何回も本番環境にデプロイ出来ているか？
  • 顧客に頻繁に価値を届けられているか？
  • 1週間：頻繁に価値を届けられているか？
    • 1週間は時間長いよね･･･
  • 業務・業種にもよるかも
    • Webならすぐにリリース可能
    • 金融ならそうは行かない？
  • じゃあ障害・バグならどう？1日で行ける？
    • 冷たい事を言えば、1日でリリース出来る。
      • →仕掛けとしては1日でリリース出来るフローが存在している。

  • Flickrのデプロイ：すごい回数。
  • ワンクリックでデプロイ出来たとしても、リリースの意志決定に時間が掛かったら無意味。
    • 戦うべきところが他にあるのかもしれない。(組織など)
  • 継続的デリバリーとは何か？
    • ビジネス部門がリリーススケジュールを握ることが出来る。
    • 常に本番環境にリリース可能
    • ボタン一発で。
  • ユーザーとプロジェクトチームの間に固いフィードバックループを作る。
  • 継続的なフィードバックプロセスは競争優位性や無駄の削減に繋がる。
  • 継続的デリバリの8原則
    • 1.SWのリリースやデプロイは繰り返し可能であり、信頼性が高い必要がある。(※人間は信頼性が低い。)
    • 2.全てを自動化する
    • 3.難解な事や苦痛な事を繰り返し行い、自動化の方法を考える。
    • 4.全てをソースコード管理システムで管理
    • 5.完了は【リリースされた事】を意味する
    • 6.品質を作り込む
    • 7.全ての人にリリースプロセスに対しての責任がある
    • 8.継続的に改善する
  • 継続的デリバリの4プラクティス
    • 1.バイナリは1度だけビルドする
    • 2.全環境デプロイするのに完全に同一のメカニズムを使う
    • 3.スモークテストの実施
    • 4.何か起こったらラインを止める
  • どの断面でも再現可能か？→再現可能でないと行けない。
  • リリースした際に、前のバージョンに即座に戻せるか？（※コードだけでなく、データベースなども含む）
  • リリースのプロセスは毎回同じ手順。
  • DRYの原則(Don’t repeat yourself)･･･自動化した方が圧倒的に楽。
  • Convention Over Configuration（設定より規約）･･･標準のものに乗っかった方が圧倒的に楽。
  • Scrumとの関連性
    • Scrum自身はこの件(自動化等)に関してはあまり触れていない。
    • Doneの定義に従ってチームが諸々自動化すればよい。


3.バージョン管理
  • いわずもがな、全ての起点はここにある。
  • コードの共同所有の原則への理解
  • ソースコードは本番・開発環境で同じように動作しなければならない
  • テストを書く習慣、コミット前にテストを含めて通す習慣
  • 設定ファイルなども原則バージョン管理
  • 全ての環境分分けて定義し、容易に切り替え可能にしておく
  • 本番環境配置の際に、アプリの各所を書き換えなければ動かない、という状況を避ける。
  • バージョン管理は開発者の『躾』。
4.テスト自動化
  • テストしてないものを目をつぶってデプロイしてはいけない
  • 清水の舞台から飛び降りない
    • 神に祈ってリリースなんてもってのほか。
  • 一日何回もリリースしようと思ったら、人手で全体をテストするのは無理。

  • テスト自動化の損益分岐点は相当早期にある感覚
    • @Ryuzeeさん曰く、『手動で一回なら自動化する価値はある』

  • アジャイルでの品質の作りこみ
    • スプリント終了＝テスト終了
    • スプリントレビューでビジネス要件の適合性も検証出来る
    • Scrumではテスト自動化については触れられていないが、アジャイル開発においてはテスト自動化は必須。
    • 自動化しないとテスト工数の占める割合が増加、価値への投資が減少してしまう。
  • テストの4象限
    • 自動化されたテストの要件
      • R：繰り返し可能
      • I：独立性
      • S：自己検証
      • E：簡単実行
  • 第3象限に関しては手動でやらざるを得ない。
  • 人手でやるのは探索的、ユーザビリティテストあたり。あとは自動化すべき。


  • テスト自動化の進め方
    • 投資割合を決めて、予めバックログに組み込むことが望ましい。一定割合を投資し続けて対応。
    • レガシーコードにおいて自動化のみに投資するのは厳しい。
  • 問題修正に掛かる時間
    • 早く見つけた方が結果として時間も短く済む。問題は早期解決が鍵。

  • リリースの判断基準：チームによって異なる（当然）
    • 早くリリースなのか
    • 品質優先なのか
5.継続的インテグレーション
  • 継続的インテグレーションの導入と7つのステップ
    • [1.ビルドサーバを用意する]
      • 大概が余っているPCでやっている。
      • 何だかんだで人的コストが結局一番高くつく。可能であれば早い、信頼性のマシンを用意すべき。
    • [2.夜間ビルドを行う]
    • [3.夜間ビルド＋コミット時のユニットテスト]
      • ※結果が帰ってくるまでに素早い反応が必要。
      • ※5〜10分以内に終わるのが望ましい。
      • ※ちなみにRyuzeeさんが関わっているとあるプロジェクトでは、1分で2000件のテストを流している。
    • [4.メトリクスの取得]
    • [5.テストに対する信頼性と依存性の確立]
      • CIに対する依存。
    • [6.自動化された受け入れテスト＋デプロイ自動化]
    • [7.継続的なデプロイ]
  • CIサーバの構築
    • コードが無くても作るべき
    • メトリクスや静的解析も初期から
      • 途中からでは極めて難しい。
    • 常にグリーンの状態を保ち、エラーがある状態に慣れない。
      • 赤に慣れている場合、プロセスに問題がある。
    • 常にグリーンを保つには、アトミックな単位での作業が必要。
    • (等々･･･)
6.マイグレーションの利用
  • CIだけだとデプロイ自動化にまでは至らない。
  • リリース時難しいのはDB。
  • マイグレーションという自動化機構を使うべき。
  • DBのスキーマの状態とリリースの状態を関連づける事によって再現可能にする。
  • 既存のアプローチの問題
    • SQLスクリプトファイルを用いた手法だと、諸々管理が面倒、制御が難しい。
7.環境構築の自動化
  • なぜ自動化が必要か？
    • そもそも時間がかかる
    • 単純作業の繰り返し
    • 単純作業はミスを誘発
    • 手順書のメンテナンスの問題 ... 等々。
  • ミドルや設定インストールの自動化
    • いつでもクリーンな動作環境を作れるように
    • 自動化によって、後はアプリをデプロイすればすぐ動作する状態に。

  • 本番・開発環境の各種バージョンを合わせる事。
    • バージョンアップの際も、この自動化機構を使う。
8.デプロイ自動化
  • プロジェクトの最初に、(デプロイするものが無くても)デプロイを自動化する。
  • プロジェクトの間ずっとデプロイスクリプトを使う事で、プロセスがテストされ続ける。
  • デプロイが失敗したらロールバック出来るように作り込む
  • 途中で失敗した場合、その先を手動でやらない。
9.テクニック
  • 基本的には自動化、ツールやスクリプトを使う。
  • ビルド(デプロイ)パイプラインという考え方。
    • SCMへのコミットをトリガーにする。
10.デモ及び質疑応答

最後の枠はとある簡単なWebアプリ(FizzBuzz結果表示)を題材にした『ビルドパイプライン』の実演デモ。

ビルドパイプラインについては以下のRyuzeeさんエントリが詳しいです。

ソースの改修・コミットから各種ステージング環境でのテスト実施まで、勉強会のタイトル通り『ワンクリック』で流れるように作業が進んで行く様を見ているだけでも充分に楽しめる内容でした。一連の流れがデモで間近に見れたことでイメージもぐっと掴みやすくなった気がします。

講演冒頭で『デプロイ自動化は、そんなに遠くないところにある』の告知文に対しツッコミが入っていたように、割と『結構遠い』感も実感したワンクリックデプロイ(＆各種ビルド自動化)。ただポイントを押さえ段階的に積み上げていけば決して難しくない道のりである事も今回の勉強会で知る事が出来ました(途中から組み込むよりも初期段階から繰り返し使い続ける事の有用性・重要性も)。

現場の環境に対してワンクリックデプロイ(＆諸々自動化)を組み込んでいくのはハードルが高そうなので、まずは個人的な開発プロジェクトでも立ち上げてその初期段階からこれら機構を組み込んでいくのが取っ付きやすそうではあるかも。年末年始、少しでもそこいらに着手出来ると良いなぁ〜。


講師の@Ryuzeeさん、発起人:@katzchangさん、会場提供に御協力頂いた@tomohnさん、そして本日御参加された皆さん、ありがとうございました！


その他関連サイト・エントリ：

※この日の勉強会を以て、2011年の勉強会参戦は終了となります(一応予定では)。
　2011年参加した勉強会回数は今回分を入れて計71回。
　365÷71＝約5日間に1回、勉強会に参戦(且つレポートUP)していた事になります。まぁ良くここまで続いたもんだ(笑)

　・勉強会参加記録一覧 - Shinya’s Daily Report
　　http://d.hatena.ne.jp/absj31/20110219/1298126974
　・勉強会参加記録一覧(ジャンル別分類) - Shinya’s Daily Report
　　http://d.hatena.ne.jp/absj31/20111127/1322407171]

　2012年も同じペースで…とまでは行かないかも知れないですが、引き続き勉強会には参加していき、
  参戦レポートも書き記して行ければと思います。

　今年1年、勉強会レポートを御覧頂きありがとうございました！
　そして来年も何卒、宜しくお願い致します。m(_ _)m