プロジェクトの展開

デプロイ プロジェクトとは?

Bamboo のデプロイ プロジェクトは、デプロイするソフトウェア プロジェクト (ビルドしてテストしたリリースと、リリースをデプロイする環境) を保持するためのコンテナーです。チームには一般的に、QA 環境、ステージング環境、および本番環境があります。 

なぜデプロイ プロジェクトを使用するのか?

継続的インテグレーションは、継続的なデリバリーを目的として設計されていません。継続的インテグレーションは、開発者が最新のコード変更の状態を常に把握できるように設計されています。

In Continuous Integration, historical build results (along with information such as issue and commits) are de-emphasised as more changes are made, since only the latest build is important to the developer.

継続的なデリバリーに従来の継続的インテグレーション サーバーを使用することは 、次の理由から理想的とは言えません。

• Deployed builds are difficult to find – Builds that were deployed only a few days ago are de-emphasised by the system. While this is good for a Continuous Integration workflow, the behaviour makes it difficult for team members to identify which builds have been deployed and when, versus which have not. Teams can work around this with a system that uses labelling but it's not immediately obvious how it should work unless team members are trained to use it correctly.
• デプロイ間でどのような変更が行われたかを明確化するのが難しい — ビルド結果は、特定のビルド結果とその直前のビルド結果との間のコミットと課題データをレポートします。2 つの異なるデプロイ間で多数のビルド結果が存在する可能性があります。多くの場合、2 つのデプロイ間の変化を完全に把握するには、2 つのデプロイ間の履歴全体をナビゲートする必要があります。場合によっては、バージョン管理システムなど、他のツールを使用しなければならないこともあります。
• 何がデプロイされ、いつ、どこにデプロイされたかを知るのが難しい — ビルドでは、コードがデプロイされた場所や、以前に環境に何がデプロイされたかを把握できません。
• Lack of insight into the QA process – Given a list of deployment candidates, builds offer no clear way (other than commenting or labelling) for QA to 'sign off' on a tested release or mark a release as broken or un-releasable.
• 誰がデプロイできるかについての管理が不十分 – ビルドを実行、表示、または編集できる権限で制御することはできますが、チームのどのメンバーが本番環境やその他の機密環境にデプロイできるかを十分にきめ細かく制御することができません。要するに、ビルドを実行する権限を持っていれば、誰もがいつでも好きなときにソフトウェアをデプロイすることができます。

これらの課題を解決するために、Bamboo は以下のコンセプトを提供しています。

• デプロイ プロジェクト — デプロイするソフトウェア (Web アプリなど)、デプロイされたソフトウェアのリリース、およびライフサイクル全体を通じてデプロイされる環境を指します。
• 環境 — ソフトウェア リリースがデプロイされたサーバーまたはサーバー グループ、およびデプロイを円滑に機能させるために必要なタスクを指します。環境の例としては、開発、QA、ステージング、本番などがあります。環境には、誰が環境をデプロイ、編集、または表示できるかをきめ細かく制御し、さらにデプロイされたリリースの全履歴を記録することができる権限があります。
• リリース — アーティファクトとそれに関連付けられたデータ (コミット、JIRA 課題、テストに使用されたビルドなど) のスナップショットを特定します。リリースにはリリース自体と以前のリリースの違いに関する情報が含まれているため、リリース間の変更や、2 つの異なる環境にデプロイされたソフトウェア間の違いを容易に確認できます。リリースが、どの環境にデプロイされたかも追跡します。

デプロイ プロジェクトの仕組み

次の図を考えてみましょう。

アーティファクト

ビルド計画でデプロイ可能なアーティファクトを作成してテストします。Bamboo でデプロイするアーティファクトには、環境のデプロイ手順で使用できるように、必ず「共有」としてフラグ付けしてください。

Releases

テストに成功したアーティファクトはリリースの作成に使用できます。リリースは好きな数だけ作成できます。Bamboo は、関連するコミットや JIRA 課題などのその他のメタデータを各リリースに追加します。これにより、各リリースが環境内を移動する様子をレポートおよび追跡できます。

Environments

Bamboo の環境は、IT インフラストラクチャの開発環境、テスト環境、および本番環境を反映しています。各環境のホスト名と認証資格情報は、デプロイ ジョブ内のタスクレベルにあります。どの時点でも、各環境でどのリリースが実行されているか、どのリリースに置き換えられたか、いつデプロイされたか、誰がデプロイしたかを確認できます。また、関連付けられた JIRA 課題も確認できます。