[DevOps]継続的デリバリの促進効果が高いケイパビリティ（2024 Advent Calendar 22日目）

この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の22日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者は全てプログラミングをするパンダです。

技術に関するケイパビリティ

本記事ではXPの継続的デリバリの促進効果が高いケイパビリティの定義と自分たちのプロジェクトでの運用を紹介します。なおこの単語は「LeanとDevOpsの科学」の書籍に登場するもので、2024年現在では技術に関するケイパビリティと呼ばれています。しかし、2022年当時の自分たちのプロジェクトを鑑みて本記事では書籍の名称をそのまま使用します。

継続的デリバリの促進効果が高いケイパビリティの定義

継続的デリバリ（CD）を促すケイパビリティには、以下の8つが挙げられています。

1. 本番環境の全ての成果物をバージョン管理システムで管理 アプリケーションコードやビルドスクリプトなど、成果物をGitなどのバージョン管理システムで一元管理することを指します。

2. デプロイメントのプロセスの自動化 デプロイを手作業で行わず、完全に自動化することで効率化を図ります。

3. 継続的インテグレーション（CI）の実装 コードに変更があるたびに、自動テストを実行し不具合を検知したり、コードを自動ビルド・デプロイする仕組みを整えることです。

4. トランクベースの開発手法の実践 アクティブなブランチを3つ以下に制限し、ブランチの寿命を短くする（1日未満など）などのプラクティスを含む、効率的な開発手法です。

5. テストの自動化 テストを手動ではなく自動で実施し、不具合を事前に検知する仕組みを導入します。

6. テストデータの管理 「必要なテストデータをすぐに入手できる」「テストデータの不足でテスト量が制限されない」状態を維持します。

7. 情報セキュリティのシフトレフト 開発初期からセキュリティを考慮し、設計やデモ段階でセキュリティチームにレビューや参加を依頼する取り組みです。

8. 継続的デリバリ（CD）の実践 ソフトウェアをライフサイクル全体で常にデプロイ可能な状態に維持することを目指します。

継続的デリバリの促進効果が高いケイパビリティの運用

これらの中で、4の「トランクベースの開発」と7の「情報セキュリティのシフトレフト」について掘り下げます。他の項目については、自分のいる組織で既に実践済みであったり、6のように試行錯誤している段階なのでここでは割愛します。

「トランクベースの開発」の運用

トランクベースの開発は複数のプラクティスの集合体です。主なプラクティスには以下のものがあります。

• バッチ単位の小さいタスクで開発する
• チーム内でアクティブなブランチを3つ以下にする
• コードフリーズをなくす
• 1日に1回はマージする
• コードの同期レビューを行う
• 自動テストを実施する
• 迅速なビルドを行う

これらのプラクティスについては、DORAのTrunk-based developmentに詳しく解説されています。

特に「バッチ単位のタスク」はスクラムのプロダクトバックログリファインメント編で、自動テストや同期レビューについてはXPの「継続的インテグレーション」「同期レビュー」編で自分たちのチームの取り組みを紹介しています。

自分たちのチームではペアプロを採用していたため、常時2～3組が並行して開発を行い、アクティブなブランチを3以下に制限できていました。コードフリーズについてはゴールデンウィークの間しかなかったので開発に全く支障は出ませんでした。。

ただし、厳密にはトランクベース開発の定義とは異なる点もありました。例えば、ブランチ運用においてはmaster、development、featureの3種類（状況によってはhotfixやrefactorも追加）を使い分けていました。このため、1日最低1回のdevelopmentブランチへのfeatureブランチのマージは心掛けており、5月と6月は2営業日を除いて全ての営業日でマージとリリースを達成しました。また、PHPを使って開発していたため、ビルドそのものが必要ないという背景もありました。この点はトランクベース開発そのものとは異なる運用の仕方です。

チームメンバーはトランクベース開発を好意的に受け止めていました。特に同期レビューや頻繁なマージによってコードのコンフリクトがほとんど発生しなかったことをプラスに感じたそうです。「開発がスムーズに進み、チーム全体でストレスが少なかった」と話すメンバーも多く、この取り組みの効果を実感しています。

8.「情報セキュリティのシフトレフト」の運用

情報セキュリティのシフトレフトについてはスクラムのスプリントレビュー編で解説した通りです。自分たちのチームでは、2週間ごとのスプリントレビューにセキュリティチームを招き、開発プロセスだけでなくビジネス側の業務フローについてもチェックしてもらいました。その結果、開発段階でセキュリティチームからのアドバイスをプロダクトに反映することができました。

特に有効だったのはリリース直前に実施したインシデント対応の予行演習です。セキュリティチームが関与してくれたおかげで、リリース後に問題が発覚して後から修正するという事態を防げたことは大きな成果です。また、こうした取り組みを通じてチーム内に「心配なことがあればまずセキュリティチームに相談する」という雰囲気が出来上がったことも非常に良かったと感じています。

このように、トランクベース開発と情報セキュリティのシフトレフトは、継続的デリバリを促進するうえで非常に重要なケイパビリティであり、自分たちのチームにおいても多くの恩恵が得られました。これらの取り組みを通して、リリースのスピードと品質の向上を同時に実現できていると感じています。

次回は、ここまでスクラム、XP、DevOpsのプラクティスを実施した自分たちのチームで、開発の生産性が実際どのようなものだったかをデータで紹介します。