« 「町田ラボ」のチーム運用を社内共有しました | トップページ | 2月の誕生日の人、その方は!? »

Capistranoでオートリリース!

全社定例会(と言っても、実質は勉強会に近い)の中の、ここ数ヶ月のレギュラーコンテンツで、
お題募集ディスカッション(以前は「即興ディスカッションと呼んでいた」)が有ります。

定例会の当日に参加者からディスカッション、或いは情報交換したい話題は有るか?、と問うて
出て来た話題についてディスカッションしようってのが当初の設定だったのですが、
どうも当日だとネタが出て来ない.....。

で、slack上に「ネタ投稿チャネル」を作っておき、思い付いたときに書き込んでおこうや!
って話になったんですが、残念ながら話題として使えるだけの書込みがなかったようです。

F1000635ので、長部さんの方で、以前の業務での経験から「Capistranoでオートリリースの実例」の紹介に端を発して、
ツールに拠る自動化に関するナレッジ共有を図ろうじゃないか、ってことになりました。

長部さんは、つい数か月前まで、某大手ECサイトの共通サービス開発・保守に関わっていました。
同じ客先に、結果的に5年以上いた(通常はこんなに長くは同一顧客先:同一サービスに関わりっ放しにはさせないのですが、「チームがとても気に入っている」という事で、無理くりアサイン先を異動して貰うことは避けて来ました...)ので、
運用方法の変遷にも詳しい。

以前はサービスの規模も大きくなかったので、手動リリースを2人組で相互チェックしながら作業していたとのこと。
(一旦運用が始まってしまえば、開発・保守で忙しい時でも継続的なリリースが発生するので、なかなか辛い...)

時と共に順調にサービスが大きくなり、物理サーバーの台数も増えたので、とても手動では追い付かなくなった
...と言うか、余りにアナクロ(=人物依存)なので、辛いしリスク高いしでやってられなくなった
(大量のコンソール(数十)を開いて、同じ作業をしなければいけない...)

そこで、デプロイ自動化ツールとして Capistrano(カピストラーノ)を導入したとのこと。
(他にも、fabricや、シェルスクリプトで対応してしまう手も有りますが...)
...と言っても、新たなツールの導入:フローの立上げには、それ自体に初期コストが掛かりますし、リスクも伴います
予算管理の責務を負っている上の人は、なかなかOKを出してくれない...。

そこで、従来の作業時間をストップウォッチで計って、総コマンド数を記録して現状のリリース運用のヤバさを説明したとのこと。
これで理解を得られて、晴れてツール導入に至ったとの事でした。

これで、コンソール1つで全サーバー環境へのデプロイ作業が効率的に行えるようになった!
 ・巻き戻しも簡単にできる。
 ・特定の実行権限・責任を負えるメンバーだけしかできなかったリリースが、マニュアルに従えば誰でもできるようになった。

デプロイのミスや、担当者不在によるアタフタも格段に減ったわけです。

この話を受けて、参加メンバーから他の顧客・プロジェクトでの話題共有が成されました

F1000632某社は、仕様的に近似点の多いサービスを複数の形態でリリースを行う必要が有り、作業が煩雑とのこと(紛らわしい)。
そこで.....
 ・ジェンキンスで自動化した。
 ・しくじった時の巻き戻しも楽ちん!
...とのことでした。

ビルドに数時間かかっていたのもが、Antを導入したら30分に短縮された例、とかも

ALTER文もふくめたリリースの自動化、巻き戻しも簡単操作で出来るプロジェクトがあった

どの案件に限らず、
リリース担当者が暗い顔をしていたら、これらのナレッジを持つ人達の協力も得つつ、必要な提案をしていければと思います!

ディスカッション、と言うか事例共有時のQAとして下記のようなものが有りました。

F1000631Q. DBカラムの追加変更と連動するリリースは?
 ⇒A. 先にDBカラムを追加しておき、後でそれを使うプログラムをリリースする
     ・MySQLの古い版では、ロックがかかるので、サービスへのアクセスの少ない時間帯に実行する。
     ・レコード件数の多い(数百万件以上の桁)テーブルは、カラム追加でなく、テーブル追加でしのぐ方向
     ・検証環境に大量件数のデータを入れて、サービス中の業務に支障が出ないかを事前に試す必要アリ

また、品質担保とコストメリットの狭間で揺れ動く例:
※JUnitと連動していたので、ビルドに時間がかかり過ぎて、いつ終ったのかわからない現場があった。
 ・昔作ったテストが動かないケースが多発して来たので、リリースに至るまでの連動からはずしたケースも。
   ・↑:元々は、自動テストがオールグリーン(OK)になるまでリリースできないルールだった...
 ・小さなサービスが次第に大きく成長したため、昔のテストが通らなくなるケースが多い

DevOpsという言葉で表現されますが、運用メンバーではなくてもリリース作業を行う例は多いのでは?
開発チームと運用チームとの間での実際のタスクの境界線は、その実施内容:リスクのバリエーション:伝達情報の量とコスト等から
判断されて、リリース辺りが境になるのでしょうね。

法的な問題も絡むようですが、リスクヘッジ(サービスを止めない)、コストメリットの点から判断・決定される例が
多いように思います。

視点を変えて言うと、アスペアメンバーとしては、DevOps全体として最適になる方向を俯瞰:提案できるように
ナレッジ共有・事例共有を進めたい
と思います!

長部さん、貴重なディスカッション:情報共有の機会を展開して戴いて、有難う御座いましたー!


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

|

« 「町田ラボ」のチーム運用を社内共有しました | トップページ | 2月の誕生日の人、その方は!? »

定例会、勉強会など」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: Capistranoでオートリリース!:

« 「町田ラボ」のチーム運用を社内共有しました | トップページ | 2月の誕生日の人、その方は!? »