バッチ処理の動作確認で開発環境を占有しないようにした話

こちらは Livesense Advent Calendar 2025 DAY 2 の記事です。

こんにちは、かたいなかです。

開発者がある一定以上の人数になったり、コーディングエージェントの支援によって開発速度が上がると、開発環境の様々な問題が顕在化します。

特に、動作確認を行うための環境が取り合いになってしまい、開発速度を律速してしまうという問題は、様々なシステムの開発生産性を考えるうえでありがちな問題なのではないかと思います。

このような問題に対して、アクセスを受け付けるサーバに対しては、プレビュー環境などの対策を以前紹介しました。

今回は、バッチ処理の動作確認で、ステージング環境を占有しないようにしたので、構成などを紹介します。

背景と課題感

マッハバイトの裏側では、多数のバッチ処理が日時指定で実行されています。

バッチ処理はEventbridge Scheduler、Step Functions、ECSを組み合わせて実行される仕組みとなっています。

これらのバッチ処理について変更を行う際には、ステージング環境にデプロイしてから動作確認を行い、問題がなければ本番環境にデプロイする、という開発フローになっています。

この動作確認を行う際、バッチ処理の実行完了待ちの時間も必要なため、ステージング環境を占有する時間が長くなってしまう問題が発生していました。

例えば、数十分かかるバッチ処理の動作確認を行っている間は、他の開発者はステージング環境での動作確認ができなくなってしまいます。もし、その動作確認の中で不具合が見つかり、修正後の内容をさらに動作確認することになると、さらに長時間ステージング環境を占有してしまいます。

このように、バッチ処理の動作確認の長期化により、ステージング環境の占有時間が長くなり、他の開発者の作業が滞らせる問題が発生していました。

この問題への対策として、ステージング環境へのデプロイを行わずに、バッチ処理を実行できる仕組みを導入しました。

まずは、ステージング環境のStep Functionsを変更し、入力パラメータとしてタスク定義が指定された場合は、ステージング環境の最新のタスク定義ではなく、指定されたタスク定義でECSのタスクを実行するようにしました。

そして、GitHub Actionsで実行したいバッチ処理とデプロイしたいブランチ名を指定すると、指定されたブランチ名のイメージが指定されたECSのタスク定義が実行されるようにしました。

ステージングでの動作確認の流れは、以下のようになりました。

言葉で説明すると以下のような流れです。

この仕組みによって、ステージング環境にデプロイせずとも指定したブランチでバッチ処理の動作確認ができるようになりました。結果、バッチ処理の動作確認時にはステージング環境を占有する必要がなくなりました。

今回の対策によって、バッチ処理の動作確認時のステージング環境の占有時間を削減することができました。

この仕組みの導入後、バッチ処理の開発を行うメンバーから、占有時間を気にせずに開発を行えるようになったという声ももらっています。

仕組みによって開発のボトルネックを解消し、スムーズな開発を行えるようにする活動は今後も継続的に行っていければと考えています。

マッハバイトの開発環境にプレビュー環境の構築をすることにより、アクセスを受け付けるサーバの動作確認もステージング環境を占有せずに行えるようにしていく計画も別途あります。そちらも進めていくことで、生成AI時代の開発速度を支える開発環境を整えていきたいです。