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

Masteries

技術的なことや仕事に関することを書いていきます.

小さい部品を組み合わせてChatOpsを作っていく話

こんにちは! Hokkaido.pmに参加すべく北海道まで来ていたところ, Gaiachanという社内Botが落ちていることを確認して復旧作業を行うなどしていた@__papix__です.

...そういえば前回Gaiachanが落ちた時は有給を使って某アニメの聖地巡礼をしていた最中で, 「佐倉ふるさと広場」というところにある風車(某アニメ2期OPで言えば, 「また扉開けようー」のところで烏丸先生の後ろに出てくる風車)のそばで復旧作業をした記憶があります.

というわけで, これはChatOps Advent Calendarの記事です. 昨日の記事は@tbpgrさんでDashでChatOpsのコマンド入力の速度と正確性を上げるでした.

宣伝

...えー, まず最初に宣伝になってしまって申し訳ないのですが, 先日発売されたSoftware Designの2016年1月号の第1特集「はじまっています。ChatOps」に, Gaiaxの若手メンバーと一緒に記事を書きました.

自分が担当した部分は, 中盤からの"そして「ChatでOperation」へ"の辺りです. Gaiaxにとって始めての「ChatによるOperation」を実装したReactioで, どのように試行錯誤をしていったかについて書かせていただきました.

Botに命令するだけで確認環境が立ち上がると便利という話

...そろそろ本題に行きましょう. 詳しい事は是非本文を読んでいただきたいのですが, 上記の記事の中で自分はChatOpsに挑戦するにあたって, 「オペレーションを小さい部品に分けて実装していく」ことを重視した, ということを書いています. 今回は, このような工夫をしておいたお陰で, チームの要望を極めて短時間に解決することができた話をしようと思います.

これまでの課題

これまでのReactio開発チームは, 基本的に各々のマシンで開発を行い, リリース前にステージング環境に上げてプロダクトオーナーなどチームメンバーによる最終確認を行う, というフローで開発を進めていました.

これは非常にシンプルなフローだと思いますが, 開発途中に開発した機能が動いている様子をプロダクトオーナーに見てもらうのが少し手間, という課題がありました.

開発者はスクリーンショットや, 操作している様子をGif画像にしてPull Requestに添付するなど工夫はしていましたが, やはりそれだけでは認識のすり合わせをする事ができず, リリース前にステージング環境で動かした時に開発者とプロダクトオーナーの認識違いが露呈し, 急いで修正する... という事が(数度ではありますが)ありました.

もちろんチームとして改善していかないといけない部分も多いですが, それと並行して「開発者が簡単に開発している機能をデプロイして, プロダクトオーナーやチームメンバーに共有出来るようにしたらいいんじゃない?」という声があがりました.

...というわけで実装された機能がこちらです.

ReactioのChatOps - プレビュー機能

現状の「ステージング」, 「プロダクション」に加えて「プレビュー」という環境を作りました. プレビュー環境は, ここまでに出てきた「開発途中のモノをのせる場所」という意味合いです.

Botに対して, preview [branch_name]のようにプレビュー環境で動かしたいブランチ名を指定すると, そのブランチのコードをプレビュー環境にデプロイしてくれます.

f:id:papix:20151220164349p:plain

立ち上げたプレビュー環境は, これもまたBot経由で停止することができます. プレビュー環境を含め, AWSのEC2上で動いているので, こまめに停止することでインスタンス代を節約できるわけです(涙ぐましい努力と言えそうですが...).

f:id:papix:20151220164336p:plain

更に, 30分に1回プレビュー環境の有無を確認して, 動いているのであれば停止を促す機能も実装しています. これで, プレビュー環境を落とし忘れてしまうトラブルを防いでいる訳です.

f:id:papix:20151220164334p:plain

プレビュー機能の実装コスト

プレビュー機能を実装するにあたって, 以下の処理をしなければなりませんでした.

  1. プレビュー用の設定を対象に, デプロイを行う
  2. インスタンスを停止する
  3. インスタンスが動いているかを確認する

1.については, 既にプロダクション環境やステージング環境に対してデプロイする為の機能と, これを呼び出すスクリプトがあったので, 後はプレビュー環境の設定(インスタンスを立ち上げるサブネットとか, インスタンスを紐付けるELBとか...)を設定ファイルに追加するだけでOKでした.

また, 2. と3. については, それ専用のスクリプトは用意していませんでしたが, それぞれChatOps実装用の道具として使えるよう, 関数として切り出していたので, その関数を呼び出すスクリプトを書くだけで提供することができました.

この辺りの, 「オペレーションの実行」部分については, 予め考慮していた部分がきっちりハマったので, 非常に低コストで実装することができました. むしろ, AWSの設定(ELBの作成等)やアプリケーション側の対応(プレビュー環境用の設定ファイルを用意する)の方が大変だったくらいです.

まとめ

寄稿した記事にも書きましたが, 「ChatOpsはチームやプロダクトの変化に"必ず"、"正確"に追随しなければならない」訳です. ...変化に追随出来ないChatOpsは, ただの「チームの足枷」です. 今回, ReactioのChatOpsにおいては, 「小さな部品を作り, これを組み合わせて実装する」ように気をつけて実装を進めたお陰で, 「プレビュー環境が欲しい!」というチームの変化に追随することができました.

ChatOpsにおける「小さい部品を組み合わせる」効果と力強さを改めて感じたので, こうやって記事にまとめさせて頂いた次第です.