NTTドコモビジネスの技術ブログ

全641件

2024/01/19

目次目次はじめに NeWork とはリリース頻度変更の背景それまでの運用課題実現方法解説日次でワークフローが起動するようにする main ブランチの HEAD にタグが付与されていなければ付与する develop に差分があれば main へのマージを自動で行う細かな工夫点 main の内容を develop に自動で取り込む祝日はリリースしないようにする自動リリース・自動 develop → main マージの制御 Slack にリリース結果を通知する stg 環境に変更内容を通知するその他の考慮上司への事前説明の省略スプリントレビュー前のリリースリリースノート品質面リリース頻度を変えてみておわりにはじめにこんにちは、NeWork 開発チームの藤野です。普段はオンラインワークスペースサービス NeWork のエンジニアリングマネジメントをしています。この記事では、それまで毎週新バージョンのリリースをしていた NeWork Web 版のリリース頻度を(最大で)毎日に変更した事例を紹介します。 NeWork とは NeWork はコロナ禍で誕生したオンラインワークスペースサービスです。従来の Web 会議ツールとは異なり、手軽に話しかけられることを重視したサービスになっており、Web・デスクトップアプリ・モバイルアプリで提供されています。サービスの基盤は GC(Google Cloud) 上で提供しており、フロントエンドは Next.js 、バックエンドは Node.js+Express を採用しています。音声基盤は NTT Com の別チームが開発している SkyWay を利用しています。リリース頻度変更の背景それまでの運用 NeWork では 2021 年 7 月以降(ほぼ)毎週のリリースを実現し、大きなインパクトのある機能だけでなく、細かな改善やバグ修正を継続して実施してきました。具体的には git flow ライクなブランチ運用をしながら毎週リリース作業をしていました。 develop から feature ブランチをきって開発し、完了したら develop にマージ。develop にマージされると自動で stg 環境にデプロイ毎週水曜のリリース日朝 : develop ブランチから main ブランチにマージ日中 : NeWork チーム全員で stg 環境を普段利用し、致命的なバグがないことを普段利用の範囲で確認夕方 : リリースタグを付与して prod 環境に自動デプロイし、動作確認重大なバグがあれば、main ブランチから hotfix ブランチをきって修正上長に状況を説明し、許可を得た上でリリース課題しかし 2 年以上この運用を続けてきていて以下の課題があると感じていました。お客さまからのフィードバックに即応してもすぐリリースできないバグがあっても重大なものじゃなければ、次のリリースまで待つ必要があるリリース直前にバタつくことがある来週まで延期したくないので、どうしても今週リリースしておきたい → 水曜の午後まで develop ブランチから main ブランチにマージできないこともあったこの駆け込み乗車によってバグがあるままリリースしてしまう可能性があった複数のスクラムチームのスケジュールに縛りを与えるスプリントレビューを通過したものだけリリースになるので、必然とスプリントの終了日が固定され重複する → 複数チームのステークホルダーは全部のイベントに参加できなくなるリリース作業の一部は手動で面倒 & ミスする可能性がある develop ブランチから main ブランチへのマージを忘れたことがある (起きたことはないが) 付与するタグのフォーマットを間違える可能性があるそれ以外でも、DevOps Research and Assessment が提唱する Four Keys のうちの「デプロイの頻度」「変更のリードタイム」を改善すべきと考えていました。実現方法上述の背景を考慮して、2023 年 9 月から以下を毎日完全自動で実施する運用に変更しました。平日の夕方に、前日の夕方以降で develop ブランチにマージされたすべての変更を main ブランチに自動でマージする main ブランチへのマージをトリガーに stg 環境へ自動デプロイ NeWork チームは基本的に stg 環境を普段から利用しているので、普段使いの範囲の中で致命的なバグがないか丸一日確認できる翌日の夕方、main ブランチにリリースタグを自動で付与リリースタグをトリガーに prod 環境へ自動デプロイ具体的には日時で起動する以下のようなワークフローを GitHub Actions で用意して実現しました。 name : daily-release on : # 平日 18:00 JST schedule : - cron : "0 9 * * 1-5" run-name : daily-release/${{ github.event.schedule }} # release タグが JST ベースの日付になるようにタイムゾーンを設定 env : TZ : "Asia/Tokyo" jobs : daily-release : runs-on : ubuntu-latest steps : - name : Checkout uses : actions/checkout@v3 with : ref : main # 全部 fetch しないと rev-list が動作しない fetch-depth : 0 # token を指定することで protected branch の設定を bypass できるようにする token : ${{ secrets.GH_TOKEN }} # 最新のタグと最新のコミットを取得 - name : get latest tag and commit id : get_latest_tag_and_commit run : | echo latest_tag_commit=$(git rev-list --tags --max-count=1) >> $GITHUB_OUTPUT echo latest_commit=$(git rev-parse HEAD) >> $GITHUB_OUTPUT - uses : actions/setup-node@v3 with : node-version : "20" - run : npm install @holiday-jp/holiday_jp - uses : actions/github-script@v3 id : is_holiday with : script : | const holiday_jp = require(`${process.env.GITHUB_WORKSPACE}/node_modules/@holiday-jp/holiday_jp`) core.setOutput('holiday', holiday_jp.isHoliday(new Date())); # Release tag の付与 - name : Create release tag id : create_release_tag if : | steps.get_latest_tag_and_commit.outputs.latest_tag_commit != steps.get_latest_tag_and_commit.outputs.latest_commit && vars.DAILY_RELEASE == 'true' && steps.is_holiday.outputs.holiday != 'true' env : # token を指定することで release 後の workflow が起動するようにする # デフォルトのリポジトリが所有するトークンでは他のワークフローがトリガーされないのは # GitHub Actionsの安全性のための仕様 GH_TOKEN : ${{ secrets.GH_TOKEN }} run : | release_tag=`deployment/scripts/get_release_version.sh` latest_tag=$(gh release list -L 1 | awk '{print $3}' ) gh release create $release_tag --title $release_tag --target main --generate-notes --notes-start-tag $latest_tag echo released_version_url=`gh release view --json url -q .url` >> $GITHUB_OUTPUT - name : Create pull request if : vars.DAILY_MERGE == 'true' env : GH_TOKEN : ${{ secrets.GITHUB_TOKEN }} id : create_pull_request run : | release_tag=stg.`deployment/scripts/get_release_version.sh day "+%Y%m%d%H%M" ` echo release_tag=$release_tag >> $GITHUB_OUTPUT latest_tag=$(gh release list -L 1 | awk '{print $3}' ) release_note=`gh api /repos/${{ github.repository }}/releases/generate-notes -f tag_name=dummy_tag -f target_commitish=develop -f previous_tag_name=${latest_tag} --jq .body | grep -Ev "dummy_tag$" | sed -e :a -e '/^\n*$/{$d;N;ba}' ` # || true をいれて失敗しても stderr.txt に書き込みがされるようにしている gh pr create --title "【定期実行】 $release_tag" --body "${release_note}" --base main --head develop -l 'auto merge' > /tmp/stdout.txt 2> /tmp/stderr.txt || true echo pull_request_uri=`cat /tmp/stdout.txt` >> $GITHUB_OUTPUT rm -f /tmp/stdout.txt continue-on-error : true - name : merge remote/main into develop if : ${{ steps.create_pull_request.outputs.pull_request_uri != '' }} run : | git config --local user.email "github-actions[bot]@users.noreply.github.com" git config --local user.name "github-actions[bot]" git checkout develop git merge main - name : push changes to remote repository if : ${{ steps.create_pull_request.outputs.pull_request_uri != '' }} uses : ad-m/github-push-action@master with : # bypass できるユーザで実行することが重要 github_token : ${{ secrets.GH_TOKEN }} branch : develop - name : Merge pull request if : ${{ steps.create_pull_request.outputs.pull_request_uri != '' }} id : merge_pull_request env : # token を指定することで release 後の workflow が起動するようにする # デフォルトのリポジトリが所有するトークンでは他のワークフローがトリガーされないのは # GitHub Actionsの安全性のための仕様 GH_TOKEN : ${{ secrets.GH_TOKEN }} # push が反映されるように5秒待ってからマージ run : | sleep 5s gh pr merge ${{ steps.create_pull_request.outputs.pull_request_uri }} --merge --subject "Merge to main for ${{ steps.create_pull_request.outputs.release_tag }}" --body "Merge to main for ${{ steps.create_pull_request.outputs.release_tag }}" - name : Get PR error if : ${{ steps.create_pull_request.outputs.pull_request_uri == '' }} id : create_pull_request_error run : | echo error=$(cat /tmp/stderr.txt) >> $GITHUB_OUTPUT rm -f /tmp/stdout.txt /tmp/stderr.txt - name : Send Slack Notification uses : 8398a7/action-slack@v3 if : always() with : status : custom fields : job,took custom_payload : | { attachments : [ { color : '${{ job.status }}' === 'success' ? 'good' : '${{ job.status }}' === 'failure' ? 'danger' : 'warning' , text : ` Github Daily Release result : $ {{ job.status }} in $ { process.env.AS_TOOK } `, } , { color : '${{ steps.create_release_tag.conclusion }}' === 'success' ? 'good' : '${{ job.status }}' === 'failure' ? 'danger' : 'warning' , text : ` Release : $ {{ steps.create_release_tag.conclusion }} $ {{ steps.create_release_tag.outputs.released_version_url }} `, } , { color : '${{ steps.create_pull_request.outputs.pull_request_uri }}' === '' ? 'danger' : 'good' , text : ` PR Creation : $ {{ steps.create_pull_request.outputs.pull_request_uri }} $ {{ steps.create_pull_request_error.outputs.error }} `, } , { color : '${{ steps.merge_pull_request.conclusion }}' === 'success' ? 'good' : '${{ job.status }}' === 'failure' ? 'danger' : 'warning' , text : ` PR Merge : $ {{ steps.merge_pull_request.conclusion }} `, } ] } env : SLACK_WEBHOOK_URL : ${{ vars.SLACK_WEBHOOK_URL }} 解説日次でワークフローが起動するようにする GitHub Actions のトリガーを schedule を使ってワークフローを自動起動するようにしています。 on : # 平日 18:00 JST schedule : - cron : "0 9 * * 1-5" main ブランチの HEAD にタグが付与されていなければ付与する以下の手順でリリースタグを付与しています。 main ブランチ HEAD のコミットハッシュと最新のリリースタグがふられているコミットハッシュを取得上述の値が合致していない = リリースできるものがあると判断してリリースタグを付与リリースタグの付与をトリガーに別のワークフローで prod にデプロイが走るようにしてありますリリースタグの付与を secrets.GITHUB_TOKEN でやってしまうと別ワークフローの起動をトリガーできないので、個人のトークンを利用していますリリースタグの計算はスクリプトを用意して自動計算するようにしています # 最新のタグと最新のコミットを取得 - name : get latest tag and commit id : get_latest_tag_and_commit run : | echo latest_tag_commit=$(git rev-list --tags --max-count=1) >> $GITHUB_OUTPUT echo latest_commit=$(git rev-parse HEAD) >> $GITHUB_OUTPUT # Release tag の付与 - name : Create release tag id : create_release_tag if : | steps.get_latest_tag_and_commit.outputs.latest_tag_commit != steps.get_latest_tag_and_commit.outputs.latest_commit env : # token を指定することで release 後の workflow が起動するようにする # デフォルトのリポジトリが所有するトークンでは他のワークフローがトリガーされないのは # GitHub Actionsの安全性のための仕様 GH_TOKEN : ${{ secrets.GH_TOKEN }} run : | release_tag=`deployment/scripts/get_release_version.sh` latest_tag=$(gh release list -L 1 | awk '{print $3}' ) gh release create $release_tag --title $release_tag --target main --generate-notes --notes-start-tag $latest_tag 余談ではありますが、 .github/release.yml と PR への自動タグ付与ワークフローを利用して、それっぽいリリースノートを自動生成するようにもしています。 develop に差分があれば main へのマージを自動で行う develop ブランチから main ブランチへの Pull Request 作成作成時のタイトルはリリースのときにも使ったタグ計算ロジックを応用しています Pull Request の description もリリースノートを自動算出するロジックを応用しています作成がエラーにならなければ (基本的にはマージできる差分があるとき) マージする main ブランチへのマージをトリガーに別のワークフローで stg にデプロイが走るようにしてありますマージを secrets.GITHUB_TOKEN でやってしまうと別ワークフローの起動をトリガーできないので、個人のトークンを利用しています - name : Create pull request env : GH_TOKEN : ${{ secrets.GITHUB_TOKEN }} id : create_pull_request run : | release_tag=stg.`deployment/scripts/get_release_version.sh day "+%Y%m%d%H%M" ` echo release_tag=$release_tag >> $GITHUB_OUTPUT latest_tag=$(gh release list -L 1 | awk '{print $3}' ) release_note=`gh api /repos/${{ github.repository }}/releases/generate-notes -f tag_name=dummy_tag -f target_commitish=develop -f previous_tag_name=${latest_tag} --jq .body | grep -Ev "dummy_tag$" | sed -e :a -e '/^\n*$/{$d;N;ba}' ` # || true をいれて失敗しても stderr.txt に書き込みがされるようにしている gh pr create --title "【定期実行】 $release_tag" --body "${release_note}" --base main --head develop -l 'auto merge' > /tmp/stdout.txt 2> /tmp/stderr.txt || true echo pull_request_uri=`cat /tmp/stdout.txt` >> $GITHUB_OUTPUT rm -f /tmp/stdout.txt continue-on-error : true ...(中略)... - name : Merge pull request if : ${{ steps.create_pull_request.outputs.pull_request_uri != '' }} id : merge_pull_request env : # token を指定することで release 後の workflow が起動するようにする # デフォルトのリポジトリが所有するトークンでは他のワークフローがトリガーされないのは # GitHub Actionsの安全性のための仕様 GH_TOKEN : ${{ secrets.GH_TOKEN }} run : | gh pr merge ${{ steps.create_pull_request.outputs.pull_request_uri }} --merge --subject "Merge to main for ${{ steps.create_pull_request.outputs.release_tag }}" --body "Merge to main for ${{ steps.create_pull_request.outputs.release_tag }}" これによって、こんな Pull Request の作成・マージまで自動で行っています。細かな工夫点 main の内容を develop に自動で取り込む main ブランチに直接行った hotfix やその他のコミットを develop に取り込むのも自動化しています。そのために専用のステップを設けてマージ・プッシュをしています。 - name : merge remote/main into develop if : ${{ steps.create_pull_request.outputs.pull_request_uri != '' }} run : | git config --local user.email "github-actions[bot]@users.noreply.github.com" git config --local user.name "github-actions[bot]" git checkout develop git merge main - name : push changes to remote repository if : ${{ steps.create_pull_request.outputs.pull_request_uri != '' }} uses : ad-m/github-push-action@master with : # bypass できるユーザで実行することが重要 github_token : ${{ secrets.GH_TOKEN }} branch : develop 余談ではありますが、我々の運用では develop ブランチは基本的に Pull Request なしでコミットできない設定にしてあるので、予めそのルールを迂回できるユーザを設定して、そのユーザのトークンを利用してプッシュするようにしています。祝日はリリースしないようにするこの運用のひとつの肝は、自動テストに頼りきらず(音声系の機能もあるため自動テスト一本に頼れるほど充実していないのが原因ですが)、stg 環境をチーム全体で丸一日にわたって通常利用したうえでリリースするところにあります。なので、単純に月曜から金曜まで毎日実行してしまうと、祝日はまったく確認しないままリリースすることになってしまいます。この問題に対応するため、以下のステップで祝日かどうかを判定しています。 - uses : actions/setup-node@v3 with : node-version : "20" - run : npm install @holiday-jp/holiday_jp - uses : actions/github-script@v3 id : is_holiday with : script : | const holiday_jp = require(`${process.env.GITHUB_WORKSPACE}/node_modules/@holiday-jp/holiday_jp`) core.setOutput('holiday', holiday_jp.isHoliday(new Date())); # Release tag の付与 - name : Create release tag id : create_release_tag if : | steps.is_holiday.outputs.holiday != 'true' 自動リリース・自動 develop → main マージの制御全部自動で動くのは基本とても良いのですが、リリースやマージを制御したいことも稀にあるかもしれません。 stg 環境で事前に確認していたら大きなバグ見つけちゃった stg 環境での確認をもっと長めにしたい働いている人が少ない状態ではリリースしたくない (年末年始とか) この要望に対して、ワークフロー自体を無効化してもいいのですが、各機能だけ個別に制御できるようにしています。(今のところ一度も活躍してないですが) 具体的には、 GitHub Actions 変数を利用してこの値を変更するだけで制御可能にしています。 Slack にリリース結果を通知する全部自動だと予期せぬエラーに気づけず大変です。なので、以下のアクションがそれぞれうまくいったかどうかを Slack で通知するようにしています。 - name : Send Slack Notification uses : 8398a7/action-slack@v3 if : always() with : status : custom fields : job,took custom_payload : | { attachments : [ { color : '${{ job.status }}' === 'success' ? 'good' : '${{ job.status }}' === 'failure' ? 'danger' : 'warning' , text : ` Github Daily Release result : $ {{ job.status }} in $ { process.env.AS_TOOK } `, } , { color : '${{ steps.create_release_tag.conclusion }}' === 'success' ? 'good' : '${{ job.status }}' === 'failure' ? 'danger' : 'warning' , text : ` Release : $ {{ steps.create_release_tag.conclusion }} $ {{ steps.create_release_tag.outputs.released_version_url }} `, } , { color : '${{ steps.create_pull_request.outputs.pull_request_uri }}' === '' ? 'danger' : 'good' , text : ` PR Creation : $ {{ steps.create_pull_request.outputs.pull_request_uri }} $ {{ steps.create_pull_request_error.outputs.error }} `, } , { color : '${{ steps.merge_pull_request.conclusion }}' === 'success' ? 'good' : '${{ job.status }}' === 'failure' ? 'danger' : 'warning' , text : ` PR Merge : $ {{ steps.merge_pull_request.conclusion }} `, } ] } env : SLACK_WEBHOOK_URL : ${{ vars.SLACK_WEBHOOK_URL }} これによって、こんな風に失敗した理由や作成されたリリースタグ・PR の情報を通知してくれます。 stg 環境に変更内容を通知する上述のワークフロー外でやっているので詳しく説明できないですが、我々が開発・普段利用している NeWork の機能のひとつであるワークスペース全体へのメッセージ機能を利用して変更内容を通知しています。ここでも GitHub のリリースノート作成機能を利用して通知内容を作成しています。これによって NeWork チームのメンバーが今日この後リリースされる内容を把握し、必要に応じて重点的な確認やバグ出しをしてくれることを狙って実施しています。その他の考慮上記の運用への変更を検討時、以下のような点についても考慮したうえで実行にうつしました。上司への事前説明の省略それまでは、週に 1 回のリリースの前に内容の説明と実際のチケットや PR のリンクを共有して上司の許可を得た上でリリースという手順を踏んでいました。頻度があがるとこれは難しくなったのですが、上司に相談したところ、運用が改善するならぜひやっていこうとのお言葉をいただき、内容の共有は週に一度かつ事後で良い(=リリースの判断に関して権限委譲して頂いた?)となりました。スプリントレビュー前のリリース NeWork は開発をスクラムで進めていました。それまでは、リリース日前日にスプリントレビューがあったので、その場でリリース可否を決めていました。 1 リリース頻度があがることでこれまでと同様のメンバーのレビューがはいったうえでリリース可否を決めるという運用はできなくなりました。ただ、スプリントプランニングにて実装する内容は事前に合意していること、リリース前に一日 stg 環境で確認ができること、リリース後に問題があってもすぐ直す or 切り戻しすればいいという意識あわせをチーム全体で行い、このフロー自体をなくしました。また、そもそもスプリントレビューしないでリリースしていいのという疑問もチーム内であがりましたが、NTT Com の技術顧問でもある吉羽さんの情報も参考に、そのような縛りがないことを確認したうえですすめました。 www.ryuzee.com リリースノート NeWork Web 版は　リリースノートを公開しています。それまではリリース毎にプロモーションチームがユーザに伝わりやすい言葉でリリースノートを作り、リリースと同時に公開していました。これもリリース頻度があがることで同じ運用を維持することが難しいのは明らかでした。これについては、リリースノートを後追いで出す運用にすることで対処しました。一方でプロモーションの理由でリリースノートやサービスサイト・ご利用ガイド等とタイミングを揃えたりものについては開発のロードマップレベルであわせてリリースすることにしています。昨年から feature flag も活用して、重要な機能のロールアウトとデプロイを分離できているのも一役買っています。品質面これまでは長いと一週間弱 stg 環境に将来リリースする機能が先行してデプロイされており、その中でバグが見つかりリリースまでの直して対処したこともありました。リリース頻度があがることでこの確認期間が短くなり、品質が悪化するのではとの声もありましたが、逆に駆け込み乗車を撲滅し、必ず確認期間が一定以上設けられるようになること・確認すべき対象が常にアナウンスされることからほぼ影響がないと判断しました。リリース頻度を変えてみて 2023 年の 9 月からこの運用をしています。元々課題に感じていた点・懸念していた点・それ以外の影響について振り返ってみます。課題 1 : ユーザからのフィードバックや軽微なバグに即応できない → 最短で翌日にはリリースできるようになって対応速度は確実に向上しました。課題 2 : リリース直前のバタつき → リリース頻度があがることで無理やりリリースにねじ込むことがほぼ 0 になりました。課題 3 : スクラムチームのスケジュールの縛り → これについては、スケジュール変更がちょっと面倒なこともあり、まだ実行に移せていません。次回チーム構成を変更する際に改めて意識していきたいと考えています。課題 4 : リリース作業の一部が手動 → 完全に自動化され快適になりました。考慮 1 : 品質面の劣化 → 今のところ以前の運用であれば防げたはずのバグの流出は一切なく、むしろ駆け込み乗車撲滅の恩恵が大きいと感じています。現在は並行して E2E テストの充実化も進めているので、この懸念はさらに小さくなっていっています。副産物 : チームの残業時間が他チームと比較して目立って減りました。(この施策だけの影響ではないかもしれませんが、) リリース作業の完全自動化の恩恵と思っています。基本的に良い影響しか出ていないので、今後も継続していこうと思っています。おわりにこの記事では、リリース頻度を毎週から毎日単位に変更した事例について紹介させていただきました。ただ、毎日リリースできればゴールではないので、引き続き自動テストの範囲拡充・信頼性向上とそれに伴うリリース頻度の向上をさらに検討できればと思っています。(そもそもリリース頻度がすべてではないですが) NeWork はどなたでも無料でお試しできますので、もしプロダクトや使われている技術に興味を持っていただけたらぜひ触ってみてください。また、2024 年 1 月現在、NeWork では一緒に開発を進めてくれる仲間を募集しています。詳細は以下のリンクをご覧ください。皆さまのご応募を心からお待ちしています！ hrmos.co スクラムガイドにも「スプリントレビューのことを価値をリリースするための関門とみなすべきではない」とある通り、いわゆるアンチパターンです。 ↩

NTTドコモビジネス の技術ブログ

コンテンツ

NTTドコモビジネスの技術ブログ