ここ数カ月、デプロイとリリースについて、同僚や友人と議論したり雑談したりする機会が数多くあった。そんな折に、友人から Facebook のリリースエンジニアリングチームについて教えてもらった。曰く、 Facebook ではリリース作業を専門とするチームがあり、そこのメンバーは開発ブランチのコミットとそれに付随する ITS の議論を精査した上でリリースに値する変更をリリースブランチへ cherry-pick するのだそうだ。
2012/07/25 追記 Facebook のリリースエンジニアリングについては Facebook のリリースと文化 - Kato Kazuyoshi を参照のこと
cherry-pick は無いわー、というのは置いておくとしても、リリースという極めて重要な作業が特定の人たちに委ねられている点に恐ろしさを感じた。嫌だと思うのはなぜなのかしばらく考えて、デプロイ作業の属人化は三段階の悪をうむのだ、と言語化できたのでそれについて書いてみる。
デプロイ作業は属人化してはいけない。チームの誰もが、いつでも、簡単に (ワンクリックで) 行えるべきだ。
なぜ属人化してはいけないのか。属人化は三つの悪をうむからだ。三つの悪に「SPOF」「特権と官僚」「お願いします脳の恐怖」という名前をつけたのでそれについて書こう。
SPOF
SPOF とはもちろん Single Point of Failure (単一障害点) のことだ。整備の行き届いていないデプロイ作業はシェルスクリプトなどを使って行われることが多い。その手のスクリプトは年季が入っていて、何人もの手垢にまみれ、複雑な引数やオプションを渡す必要があり、ドキュメントは皆無なので、ソースを読んで挙動を把握しなければまともに使うことができない。しかしソースを読む気概のある人はそう多くないので、必要に迫られて使い方を学んだ人がなし崩し的にデプロイ担当者にされてしまう。
他のチームメンバーからすれば、その人にやってもらえばすぐ済む作業なので、自分も学ぼうというモチベーションがわきづらい。一方で不幸にもデプロイ担当になってしまった人は作業に慣れるので、他の人にやり方を教えるよりも自分でやったほうが楽だと感じるようになる。こうして、特定の誰かしかデプロイのやり方を知らない、という危険な状況がうまれてしまう。
特権と官僚
SPOF を無くすのは簡単だ。担当者を増やせばいい。当番制にするとか、デプロイ作業を行うミニ・チームを作るとか、アプローチは様々だ。しかし、これは新たな問題をうむ。デプロイできる人たちは他にはない特権を握っている。持つものと持たざるものがいればそこには階級がうまれる。特権階級が気のいい奴らだったら平和だけど、貴族と庶民はいがみ合うものと相場が決まっている。この場合、権力は先天的なものではないので官僚と呼ぶほうが適切だろう。
官僚の二文字から気のいい奴らを連想する人は少ないと思う。特権階級は偉く立場が強いので、あらゆる物事は彼らの都合や思惑に従って動くようになる。デプロイ担当者が「金曜日のリリースは認めない」と言えば、たとえ大口のクライアントから金曜の夕方に大至急の差し替えを指示されても、月曜まで待ってもらわなきゃならない。そこまでひどいのはさすがにないとしても、デプロイ担当者のスケジュールを押さえるのが重要な社内調整タスクになる、なんてことはありうる。再来週は彼が休暇をとる予定なので毎日コンテンツを更新するキャンペーンの受注は一ヶ月ずらしましょう、とか、身に覚えがある人もいるんじゃないだろうか。
お願いします脳の恐怖
鼻持ちならないエリート集団が幅を利かせるのはいけ好かないものだが、実はそんなのは最後の悪に比べれば大したことはない。パワーバランスが変われば簡単にひっくり返せるからだ。でも、デプロイ作業を「お願いします」と言い続けてチームメンバーが「お願いします脳」になってしまうと事態は極めて深刻になる。
デプロイを「お願い」するというのがそもそもおかしい、と思う。仕事なんだからお願いもクソもない。個人的には「お願いするくらいならデプロイツールのソース読んで自分でやったほうがマシだから俺にも特権を寄越せ」というタイプだけど、お願いしてやってもらうしきたりになっていたら多くの人はそれにならうだろう。それだけならいい。でも「お願いします」と言い続けると、自分でやろうという発想そのものが失われていってしまう。
「お願いします脳」を個人の過失というのはちょっと気の毒かな、と思う。彼らは間違ったやり方の犠牲者だ。お願いしなくてはできない作業があるので仕方なく頼んでいただけなのに、知らず知らずのうちに「自分で勝手にやるよりもお伺いをたてたりお願いしたりするほうがよいのではないか」という雰囲気に絡め取られていく。そして、遅かれ早かれ「自分で勝手にやるなんてもってのほかだ」と考えるようになる。
これはもう洗脳と言っていいかもしれない。長い時間をかけてじわじわと脳を蝕まれる。やっかいなのは主犯が不在なことだ。「ある種の作業は専任者にお願いしてやってもらうものなのだから、個人がでしゃばって何でも自分でやりたがるのは良くない」という空気が悪い。そして、空気は目に見えないし匂いもないので、一度蔓延してしまうと払拭するのは難しい。
属人化を避けるには: 例えば Webistrano を使う
デプロイ作業が属人化すると、デプロイ担当者という SPOF がうまれ、特権を握った貴族たちが官僚的に振る舞うようになり、庶民はじわじわと洗脳されて脳を去勢される、という弊害について (誇張した表現をまじえながら) 述べた。諸悪の根源はデプロイ作業が複雑なことだ。簡単に使えるツールに乗り換えることでこの問題を解決し、最悪のシナリオを回避できると考えている。
僕の場合は Webistrano を使った。これは Capistrano というコマンドラインから利用するデプロイツールをブラウザから操作できるようにした代物で、ボタンを押せばワンクリックでデプロイできるようになる。使い方を覚える必要はほとんど無い。デプロイ操作用ページの URL を開いてボタンを押すだけ。ヤフーで検索できる程度のネットリテラシーを持っていれば誰でも、マネージャーでもバイトでも社長でも掃除のおばちゃんでもできる。
Webistrano に乗り換える前は長年コマンドラインツールのお世話になっていたが、デプロイ担当者である自分ですらしばしば正しい使い方を忘れてシェルの history が頼みの綱だった。大事なリリースの日に体調を崩して迷惑をかけたこともあれば、自分の仕事に集中していたときに「お願いします」の割り込みが入ってイラッとしたこともあった。 Webistrano への乗り換えは社内で前例があったとはいえほぼ僕の独断で行ったが、チームメンバーにはおおむね好評だ。自分でできることが増えるというのは、それだけでうれしいものなのだろう。
リリースエンジニアリング不要論
デプロイと同じくリリース作業も属人化を避けたほうがいいと思っている。理由は全く同じなので繰り返さない。でも、ここには自分のなかでまだ葛藤がある。 Subversion や Git などのバージョン管理システムをまともに利用している場合、リリースとはつまりマージのことで、それは開発者が行うべきことだから、ワンクリックでできるようにすればいいというものではない、のかもしれない。
Webistrano と Jenkins を組み合わせて、開発者以外のチームメンバーもリリース作業をブラウザからできる仕組みを作ったことがある。 gitflow を使っているプロジェクトだったので、 git flow release start XXX からはじまり git push origin master で終わる一連のコマンドを自動実行する Job を定義して Webistrano から kick するようにした。実際使ってみると、まどろっこしくてかえって使いづらかった。これならチームメンバー全員に手順書を配るほうがマシだったかも、とちょっと後悔している。今後も模索することになると思う。
ただ、ワンクリックリリースはやりすぎだったとしても、数名程度のチームではリリースのための作業は不要だし、そんな作業が発生しない仕組みを維持したまま大きくなるのが理想だよな、という考えは揺らいでいない。得意げに svn merge してさも仕事をしたような顔をしていたらダメなんだ (一年か二年前の自分がまさにそういう奴だった) 。そんなところで貴重な時間を費やさなくてもいいようにするためには何を変えればよいのか、それを考えて実践することにこそ時間を使うべきだ。リリースエンジニアリングという仕事を無くすことがリリースエンジニアリングの究極の目的なんじゃないだろうか。
deployment hogehoge?
デプロイやリリースというのは組織におけるワークフローやビジネスと密接に関わりあっているので、なかなか組織を超えて知見を共有しづらい。だからこそ他のみんながどうやっているのか気になるし、自分の悩みを打ち明けていろいろ意見ももらいたい。そんなことをぼんやり考えていたら、風のうわさでそういう話をする会の計画があることを知った。
deployment hogehogeのお打ち合わせしてた #shibuyarb
— Ryoichi SEKIGUCHI (@ryopeko) July 18, 2012
仮名称からしてまだまだふんわり、もとい hogehoge している感じではあるけれど、こういう機会があれば Webistrano にまつわる話などを発表させてもらいたいと思っている。プレゼン資料のほうが図などもあってパッと見で理解しやすいと思うので (っていうかブログに長文書いても読まれないしね...) 発表の機会のあるなしに関わらず一回まとめておきたい。
