こんにちは。Webアプリチームの村岡です。
コロナの影響で外出しづらい日々が続いていますが、せめて気分だけでもとZoomのバーチャル背景を風景にして日々旅行気分を味わっています。
今回はオープンワークのリリースとその自動化についてのお話です。 オープンワークの開発のスピード感と、効率化の取り組みについてお伝えできればと思います。
オープンワークのリリースは最大週に16回
オープンワークでは規模の大小は問わず、ほぼ毎日リリースが行われています。 月曜から木曜まで（祝前日は除く）の週4日、一日に最大4回行っています。 今日依頼のあった改修タスクが、明日にはリリースされている、なんてこともよくあります。
ですが、日々サイトが目まぐるしく発展していく一方で、リリースについては課題も多くありました。
自動化以前のリリースにあった問題
問題点その１：膨大かつ複雑な作業
OpenWorkサイトのリリースでは、以下のような作業が毎回必要になってきます。
- リリース予定の整理
- リリース手順のチェック
- リリースブランチの作成
- ステージング・本番環境へのデプロイ
- デプロイが終わったらSlack上で開発担当者へ連絡
- masterブランチへのマージ
- リリース記録（Backlog）の作成 etc...
なるべくシンプルに書きましたが、ここに含まれない作業も多数存在します。 手順や作業内容を覚えるだけでも大変ですし、毎回作業するにも時間がかかります。
問題点その２：オペレーションミスのリスクが高い
OpenWorkのサイト全体に関わることですので、そのリリースに失敗した時のリスクは当然極めて高いです。 ちょっとしたミスや気の緩みが大きな問題に繋がりかねないので、作業時は気を抜けません。
実際にあった事故：サイトが動かない！？
実際、過去にオペレーションを誤ったために一時的にサーバーダウンしてしまったこともありました。。
問題点その３：特定のメンバーへの負荷
リリース作業は権限の関係上、作業できるメンバーが限られます。
問題点１〜２で挙げたことと合わせると、リリース作業を行う日はほぼ作業にかかりきりになります。 ですが、担当者は専任でリリース作業をしているわけではなく、他のメンバーと同じようにプロジェクトにアサインされています。 なので、その分本来のタスクに割ける時間も減り、生産性も落ちてしまっていました。
（他人事のように語っていますが、私もリリース作業の担当者です）
解決策→「そうだ、自動化しよう」
当初、有志メンバーで自主的にリリース業務の改善を行っていましたが、出来ることには限界がありました。 またちょうどエンジニアのメンバーが増えてきたタイミングでもあり、それまでのリリースフローだと対応しきれない部分も出てきていました。
そこで、ちょうど二年前の今頃、会社としてこれらの問題に取り組むために「リリース改善チーム」が結成されました。 そして、その取り組みの主たるものが、「リリースを自動化する仕組みを作る」ことでした。
現在のリリース作業––Slackから行うリリース作業
弊社ではコミュニケーションツールとしてSlackを使っているため、Slackからリリースができるようにbotを作成しました。 現在はこのbotにより、作業の九割ほどは自動化されています。
詳細はまたの機会にお話しさせていただければと思いますが、大体以下のような仕組みです。
- リリース予定は各自が専用カレンダーに予定を登録する
- 毎日定時になると自動で翌日のリリース予定を読み取ってSlackに通知
- 通知されたリリーススレッドに添付されているボタンを押すことで各開発担当者がリリースが進められる
- 本番へのデプロイ時のみ、特定のメンバーが作業する
- リリースに必要な作業は（ほぼ）全て自動で行われる
結論：リリース作業時にすることは、Slack上のボタンを押すだけ！ もちろん、気は抜けませんが……
これらの仕組みを一から考えて実現するのは大変な作業でしたが、それに見合うだけの成果を得られたと考えています。
最後に
上の項目で「（ほぼ）全て自動で行われる」と書いた通り、一部の作業はまだ自動化されていません。 そこを解決し、「全て自動化する」ことが目下の目標です。
現状のリリース自動化の仕組みも完璧なものではないので、どんどん改善していく予定です。 （興味のある方、大歓迎です！）
