プロジェクトの展開
デプロイ プロジェクトとは?
Bamboo のデプロイ プロジェクトは、デプロイするソフトウェア プロジェクト (ビルドしてテストしたリリースと、リリースをデプロイする環境) を保持するためのコンテナーです。チームには一般的に、QA 環境、ステージング環境、および本番環境があります。
なぜデプロイ プロジェクトを使用するのか?
継続的インテグレーションは、継続的なデリバリーを目的として設計されていません。継続的インテグレーションは、開発者が最新のコード変更の状態を常に把握できるように設計されています。
継続的インテグレーションでは、開発者にとって重要となるのは最新のビルドのみのため、変更を加えるたびに過去のビルド結果 (および課題やコミットなどの情報) は重要ではなくなります。
継続的なデリバリーに従来の継続的インテグレーション サーバーを使用することは 、次の理由から理想的とは言えません。
- デプロイされたビルドは見つけるのが難しい — 数日前にデプロイされたばかりのビルドでも、システムによって重視されなくなります。これは継続的インテグレーションのワークフローには良いことですが、この動作により、チームメンバーはどのビルドがいつデプロイされたか、どのビルドがデプロイされていないかを特定するのが難しくなります。チームはラベル付けを使用するシステムでこれを回避できますが、チームメンバーがラベル付けを正しく使用するためのトレーニングを受けていない限り、どのように機能しているかは一見わかりません。
- デプロイ間でどのような変更が行われたかを明確化するのが難しい — ビルド結果は、特定のビルド結果とその直前のビルド結果との間のコミットと課題データをレポートします。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 labeling) for QA to "sign off" on a tested release or mark a release as broken or un-releasable.
- 誰がデプロイできるかについての管理が不十分 – ビルドを実行、表示、または編集できる権限で制御することはできますが、チームのどのメンバーが本番環境やその他の機密環境にデプロイできるかを十分にきめ細かく制御することができません。要するに、ビルドを実行する権限を持っていれば、誰もがいつでも好きなときにソフトウェアをデプロイすることができます。
これらの課題を解決するために、Bamboo は以下のコンセプトを提供しています。
- デプロイ プロジェクト — デプロイするソフトウェア (Web アプリなど)、デプロイされたソフトウェアのリリース、およびライフサイクル全体を通じてデプロイされる環境を指します。
- 環境 — ソフトウェア リリースがデプロイされたサーバーまたはサーバー グループ、およびデプロイを円滑に機能させるために必要なタスクを指します。環境の例としては、開発、QA、ステージング、本番などがあります。環境には、誰が環境をデプロイ、編集、または表示できるかをきめ細かく制御し、さらにデプロイされたリリースの全履歴を記録することができる権限があります。
- Release – 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 release contains the information of the difference between itself and the release beforehand, it's very easy to see the changes between releases or to show the difference between the software deployed on two different environments. Releases also track what environments they have been deployed to.
デプロイ プロジェクトの仕組み
次の図を考えてみましょう。
On this page:
継続的なデリバリーとは?
Continuous Delivery is the practice where all changes made to a software project are automatically built, tested and made ready for deployment to users. In practice, once the project has been built and tested it is "staged" somewhere where it can be manually verified and then made available to users.
継続的デプロイ (コードの変更が人間の介在なしに自動的にビルド、テスト、デプロイされるプロセス) とは異なり、通常、ソフトウェアの品質が十分かどうか、または企業がユーザーに対してソフトウェアを利用可能にする正しいタイミングかどうかは、人間が判断します。
アーティファクト
ビルド計画でデプロイ可能なアーティファクトを作成してテストします。Bamboo でデプロイするアーティファクトには、環境のデプロイ手順で使用できるように、必ず「共有」としてフラグ付けしてください。
Releases
Any artifact that has been successfully tested can be used to create a release; you can create as many releases as you like. Bamboo will add other metadata such as related commits and Jira issues to each release 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 release is running in each environment, which release it replaced, when it was deployed and who deployed it. You will also be able to see any associated Jira issues.