ワンクリックデプロイ勉強会 #ocdeploy へ行ってきました
ワンクリックデプロイ勉強会へ行ってきました。品川で12月に開催された内容の再演だそうです。
- ワンクリックデプロイ101 #ocdeploy http://www.slideshare.net/Ryuzee/101-10647187
前回のスライドを拝見して気になっていたので、聴けて良かったです。[twitter:@ryuzee]さん、会場提供くださったアットウェアさん、スタッフの皆さん、ありがとうございました。
以下は、感じたことのメモです。内容のまとめにはなっていませんので、中身が気になる方は、ryuzeeさんのスライドをご覧ください。
Flickrは毎日10回くらいリリースしている、という話を聞いて
この話を聞いて真っ先に思ったのは、毎日リリースすることを是とするシステムばかりではないだろう、ということでした。ただし、BtoBだからできないとか、大規模だからできないとかいった言い訳や反抗をしたくなったのではありません。
頻繁なリリースを要求しないシステムもまた、どんなデプロイ方法を採用すればミスを減らせるかを考えて実践することが、本来は必要でしょう。今はそれをできていないな、ということに思い至りました。
障害時にテスト完了から1日でリリースできるなら、平時でもできるハズ
会場に対して、「テスト完了後、どれくらいの時間でリリースしますか？」という質問がありました。
平時にはテスト完了からリリースまでに1週間以上かけているプロジェクトでも、障害時の緊急リリースでは、1日やそこらでリリースすることがままあります。であれば、日頃からその速さでデプロイ作業ができるのでは、という話でした。
いわれてみれば、そうですね。ただ、障害時は、火事場の馬鹿力も多分に発揮される気がしますｗ
間違いそうな作業、苦しい作業をこそ自動化しよう
これは、自動化が有効な作業の説明として、とても分かりやすい言葉だと思いました。自動化について人に説明するとき、借用させてください ;-)
データベースのバージョンも管理するべし
「ソースコード同様、DBのスキーマとデータもバージョン管理して、いつでも特定のビルドに戻せるようにしよう」というお話がありました。
最初に聞いた時、次のどちらの話なのか分かりませんでした。
- あるビルド時点のDBのスナップショットをリストアする
- あるビルド時点のスキーマに合わせて、最新のデータを変更する
…もちろん、前者の話だったわけですが。（常識的に考えて、後者は至難の業ですね。でも、もしかしたらと思ったのです）
現実的には、すべての過去のビルドに戻せるようにすることは難しいです。でも、直前のビルドの分くらいは、DBをデータごと取っておき、何かあったら戻せるようにしよう、といった意図だそうです。
余談ですが、「あるビルド時点のスキーマに合わせて、最新のデータを変更する」アプローチは、難しそうですが、もし可能であれば有用な局面もありそうです。そういうDBの進化のさせ方が、すでにあるのではと思ったのですが、どうなんでしょうね。
「何ができたらリリースできるか（完了の定義）」を決める
デプロイ自動化の仕掛けによって機械的にリリースしてしまうのではなく、ビジネスに必要なリリース基準を設けてチェックすることは必要、というお話でした（自分はそう解釈しましたが、ちょっと違うかもしれません…）。
ところで、このくだりの前に、「チームが解決できない問題は組織的な問題である」というお話がありました。
本質的に機械化、自動化できない「完了のための作業」こそが、組織的な問題によってボトルネックになりうる部分なのだろうと想像します。
ただ、そこに対してどうすればよいのかは、まだよく分かりません。
テストを自動化しないと、顧客に届けられる価値が徐々に減っていく
この話は、実感を持って聴きました。
開発に使える時間から、回帰テストにかかる時間を差し引いたら、新機能の追加にかけられる時間が少ししかない、という事態は、たしかによくありますね。
ツールの利用に関して
参考になる考え方と小技をいくつか聞いたので、まとめてメモします。
デプロイの自動化もCIも、開発の最初から導入する
- 最初からデプロイを自動化しておくと、デプロイしやすいコードになる
- デプロイ先のディレクトリ構造をシンプルに保つ、等
- コードが腐る前にCIサーバを立てる
Capistranoまわり
Capistrano（https://github.com/capistrano/capistrano）は、SSHのコマンドを自動化するツールです。
- 環境切り替えの設定ファイルもバージョン管理する
- 環境切り替えは、デプロイのタスクに組み込む
- バージョン番号の付与も自動化する
- Capistranoなら、直近のバージョン番号を保存できる
- DBにバージョンを保存しておき、参照してインクリメントする方法もアリ
- マイグレーションのバージョン番号も、DBで管理する
- 設定ファイルにパスワードなどは書けないが、自動化のアプローチはある
- 権限を絞ったリポジトリを使う
- 設定ファイルからはパスワードを抜いておき、Capistranoの対話モードを使って、cap deploy時に設定する
全体の感想
リリースの頻度と自動化の要否（範囲）は、密接に関係していると感じました。頻繁にリリースしたければ、テストを自動化するしかないのではないか――それも、可能な限り広い範囲を――その一方で、そこまで頻繁なリリースは不要であれば、自動化もそれなりにバランスを見てやればよいのではないか、と感じました。
また、質疑応答で何度か出た、自動化の推進方法のお話も良かったです。
ときどき聞く「開発者が安心して開発をするために自動化しよう」という意見は、開発者の共感を呼びますが、ともすれば論理を向こうにやってしまう側面もある理屈です。組織によっては通用しづらいでしょう。そういう場では、ryuzeeさんがおっしゃるような「現在これくらい時間と人がかかっている作業が、自動化によってこれくらい小さくなります。ホラお得でしょう」という説得の方が、機能しうると思います。
そして、「チームやプロダクトにとって良いことであれば、組織のルールはさておき、黙って実行してしまうのもアリ」というお話には、デブサミのヨシオリさんの話に通じるものを感じました。
良い方法を模索したいと思います。
