はじめまして。Webアプリエンジニアの村井です。
OpenWorkリクルーティングのプロダクトチームで2年弱、開発リーダーをしていました。大きな案件の開発、スクラム導入、複数プロジェクト合同での開発......など色々なことがありました。
今回、その中でもリリースに悩んだエピソードを紹介させていただきます。
データの整合性や下位互換性を考える案件
Web開発をしていると、稼働中のサイトに改修したソースを追加するにあたって、リリース前後の流れを考える機会があります。(ログインセッションが切れないこと、APIやフォームの下位互換性など)
私が携わったグループ管理機能を開発する案件では、以下の仕様を実現しようとしていました。
仕様
- すべてのユーザは何らかのグループに所属する
- ユーザは所属しているグループの情報のみ参照できる
最初に考えたこと
上記の仕様を実現するために、最初は以下の流れでリリースしようかと考えました。
- データを作成する(既存のユーザーに初期グループに所属させる)
- デプロイする
- 新規登録ユーザーは、登録時に初期グループに所属して、ログインができる
- デプロイ前から存在するユーザーは、データ作成によってグループに所属しているため、ログインができる
ただ、この手順だと、データ作成〜デプロイの間に新規登録したユーザーはどこのグループにも所属していないことになります。
該当ユーザは一時的に機能が利用できない状態となってしまうため、何らかの対応が必要でした。
実際はどうしたか
サービスを停止(メンテナンス状態を表示)してリリースすることも一度検討しましたが、デプロイを細かく分けることでサイトは無停止のまま安全にリリースできると思い直しました。
1回目のデプロイでは裏側でデータを作成するソースのみ、 2回目のデプロイではデータがある前提での管理機能のソース という形で、デプロイを2回に分けました。
- デプロイする
- 新規登録ユーザーは、登録時に初期グループに所属する
- データを作成する( グループに所属していない 既存のユーザーに初期グループに所属させる)
- デプロイする
- デプロイ前から存在する全てのユーザーはグループに所属しているので、問題無くログインできる
結果、リリースは無事に完了し、小さくデプロイしたことで1リリースあたりの負荷やリスクを減らすこともできました。
小さく早くリリースしていきたい
サービスを利用している方へ最大限価値を提供するために、いかに早くリリースするかは大事ですよね。
なるべく小さな単位で高頻度でリリースしていくことが理想だと思います。(修正差分行数とリリース時の緊張感は比例すると思っているので、エンジニアのやりやすさから見ても1回ごとの負担を小さくしたいものです......)
小さく高頻度でリリースするために、
- コードの保守性を高める
- 本当に必要な要件を見極める
という意識が、エンジニアだけではなくチーム全体で共通認識としてあると良いと感じます。
オープンワークでは、チーム全体でサービスをより良くする開発に取り組んでいます。
プロダクトマネージャー、デザイナー、アナリストなどエンジニア以外のメンバーもエンジニアリングに理解があり、エンジニアもどうしたら早く良いものをリリースできるかを一生懸命考えています。
大きい案件では、自分の思いついてない考慮すべき事項はたくさん潜んでいるし、問題は無いと考えていてもやはりリリースのときは緊張します。
些細な意見でも気軽にフラットに言い合える環境を作るため、チームメンバーとの相互理解や信頼関係は大事な要素だとこの2年弱開発リーダーを経験してきて実感しました。
最後に
裁量を持って開発がしたい!
同じモチベーションを持ったメンバーと一緒にプロダクトの価値を高めていきたい!
そんな方には、きっとオープンワークは楽しい環境だと思います。
この記事を読んでオープンワークに少しでも興味を持った方は、ぜひ採用サイトを覗いていただけると嬉しいです。