Build Once, Continuous Delivery - ビルドワンスと継続的デリバリー

[#1]

アイデアをビジネス価値にし続ける

講演では実例としてデモンストレーションを実施していますが、

                アイデア → ビジネス価値

を継続的に実践するための一例を提示しています。

継続的にデリバリーするためには、ビルドパイプラインやそれらの自動化だけでは不足していて、継続的フィードバックを実現する要素をカバーしておく必要があります。そこには、プロダクト戦略、バックログ戦略、ブランチ戦略、ビルド戦略そして、デプロイ戦略が一連の『流れ』として持続可能である必要があります。

『流れ』をつくる

開発用環境は、開発者が自由にアクセスできる環境です。継続的インテグレーションをするたびに、構築・実行できるようになっています。私のデモ環境では、コードに変更を行う場合は、Git ブランチを作成し、コードを分離します。そこで起きた変更についても、継続的インテグレーション (CI) が実施され、Docker コンテナが作成されます。したがって、このコンテナを実行すれば、その開発目的に応じてコード変更した環境を開発者個別に提供してくれるのです。

この流れとバックログが繋がっていないと複雑な開発現場はマネージできません。

話を戻して、master ブランチにて CI が成功すると、Docker イメージが保持されるようにしていますので、デプロイ時にもう一度ビルドするなんて愚は行いません。CI でビルドすればあとは、どの環境にデプロイするかだけでよいわけです（Build Once）。

CI サーバーのレポートで見てましょう。

各開発目的ごとのブランチでも CI が実行されていることも右下のレポートを見ればわかります。

これをビルドパイプラインでみると以下のようになります。

* Bamboo のアドオンを使うとビルドパイプラインを可視化し、実施状況のリアルタイム把握もできるようになります。

一番上のが master での  CI  です。ビルドレベル「A」です。

さて、これをどうデプロイするのかを見てみましょう。まず、CI のプロジェクトからみてもどのビルドがどこの環境にデプロイされているのかはわかります。

Stating には、Release-44 というのがデプロイされていることがわかります。この Release-44 では、ビルド 20 がつかわれていることがわかります。Production も同様だというのが確認できます。

これをみると、ステージング環境には、CI が成功するとそれをトリガーにしてデプロイが行われたこともわかります。これは、デプロイプロジェクトのトリガーで設定していたためです。では、デプロイメントの設定を見てみましょう。

この「Triggers」を見てみましょう。

最後にデプロイのワークフローを見てみましょう。

ちなみに、Bamboo では、タスクとして、標準で Docker タスクが備わっています。

継続的デリバリーの全体像

全体像は、以下の図になります。今回は、ビルドとデプロイのところを見ていきました。