読者です 読者をやめる 読者になる 読者になる

by shigemk2

当面は技術的なことしか書かない

毎日が憧れの新築、反復可能なデリバリーによる常時新築システム #juc2012

Jenkins ユーザ・カンファレンス 2012 東京

PaaSにおける3種類のデプロイ

アプリのデプロイ
利用者A→利用者Aのアプリ→利用者Aのシステム→PaaSバックエンドシステム

手動書による手動デプロイ 手動クラウドへのデプロイ 常時結合している
デプロイ 工数 理想値で8人日(実際は理想値の倍程)

ある種のドッグフーニング

→大きなデプロイ工数によるさぼり
既存のデプロイには差分だけ適用
新規顧客を探しに行きにくくなる

手動書→Chef Solo(記述が簡単+セットアップも楽)

  • パッケージの集約
    • ビルド後にパッケージ集約ジョブを呼び出す
    • ビルドジョブからアーティファクトをコピー など
  • マシンの用意
    • 各種CloudPlugin(Amazon EC2 Pluginなど)
    • 任意のタイミングでVM制御が必要
    • デプロイ手順としてリブート
    • マシンに直接ログインして試行錯誤
    • Java, Git, Ruby, Chef-soloをインストールしたテンプレートVMを用意
    • テンプレートからVMを作りそこにデプロイ
  • デプロイの実行
    • ノードにまたがって逐次実行など
    • PaaSバックエンドシステムは複数台
    • Parameterized Triggerで各スレーブにデプロイ

ソースレポジトリ ビルド用スレーブ デプロイ用スレーブ Jenkinsマスター
必要に応じてスレーブを作成する

スローデプロイ問題

  • デプロイに60分かかる
  • スローテスト問題は、テストケースを分割し、複数のマシンで並列にやらせるのが一つの解
  • でもテストは並列化できるがデプロイは並列化できない

60分かかるデプロイのうち、45分はネットワークのI/Oまち

  • VMスナップショットへの復元

VMを新しくテンプレから作るかわりにスナップショットを作る
(10分から3分に短縮できる)

  • インターネットからの分離

rpmやgemのダウンロードが死ぬほど遅い。
事前にアーティファクトを集める (45分から2分に)
外部環境の原因を追求しやすい

自前と既成の分割と羃等性

f(f(x)) = f

自前パッケージ
自前のソースからビルドするパッケージ
既成パッケージ
他社が作ったパッケージ

更新頻度もインストール所要時間も自前のほうが短い

羃等ではない

$ tar zxf foo.tar.gz

羃等

$ rm -rf foo
$ tar zxf foo.tar.gz

自前と既成のパッケージを別々にインストールすることで、
最短2分でデプロイが終わることもありうる
(再度実行することも可能だから)

Fail Fast

失敗するなら早い失敗を目指す
設定ファイルではなく設定ファイル作成プログラム

環境の使い捨て

本番と同じ環境で開発
高速なデプロイと羃等なスクリプトのおかげ

ブランチごとにデプロイ

まとめ

  • ビルドだけでなくデリバリーも自動化
  • クリーンと羃等で反復可能に
  • 自動化だけで終わらせずに高速化も検討する
  • 迅速なフィードバック
  • 速ければ使い方も変わる