プロジェクトの展開

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

A deployment project is a container for holding the software project you are deploying: versions that have been built and tested, and the environments to which versions are deployed. Teams typically have QA, staging and product environments. 

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

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

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 version or mark a version as broken or un-releasable.
• 誰がデプロイできるかについての管理が不十分 – ビルドを実行、表示、または編集できる権限で制御することはできますが、チームのどのメンバーが本番環境やその他の機密環境にデプロイできるかを十分にきめ細かく制御することができません。要するに、ビルドを実行する権限を持っていれば、誰もがいつでも好きなときにソフトウェアをデプロイすることができます。

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

• Deployment project – Represents the software you are deploying (such as a web application), the versions of the software deployed and the environments that they will be deployed to throughout the lifecycle.
• Environment – Represents the servers or groups of servers where the software version has been deployed to, and the tasks that are needed for the deployment to work smoothly. Typically, these environments can be named QA, Staging and Production. Environments have permissions that allow fine grained control of who can deploy, edit or view an environment and record the full history of versions deployed to it.
• Version – Identifies a snapshot of artifacts and its associated data such as commits, JIRA issues and the builds that were used to test it. As a version contains the information of the difference between itself and the version beforehand, it's very easy to see the changes between versions or to show the difference between the software deployed on two different environments. Versions also track what environments they have been deployed to.

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

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

アーティファクト

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

バージョン

Any artifact that has been successfully tested can be used to create a version; you can create as many versions as you like. Bamboo will add other metadata such as related commits and JIRA issues to each version which enable reporting and tracking as it moves through your environments.

Environments

Environments in Bamboo reflect the development, testing and production environments in your IT infrastructure – hostnames and authentication credentials for each environment reside at the task level inside your deployment jobs. At any point in time, you will be able to see which version is running in each environment, which version it replaced, when it was deployed and who deployed it. You will also be able to see any associated JIRA issues.