デプロイ プロジェクトとは?
A deployment project is a container for holding the software project you are deploying: releases that have been built and tested, and the environments to which releases are deployed. Teams typically have QA, staging and production 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 release or mark a release as broken or un-releasable.
- 誰がデプロイできるかについての管理が不十分 – ビルドを実行、表示、または編集できる権限で制御することはできますが、チームのどのメンバーが本番環境やその他の機密環境にデプロイできるかを十分にきめ細かく制御することができません。要するに、ビルドを実行する権限を持っていれば、誰もがいつでも好きなときにソフトウェアをデプロイすることができます。
これらの課題を解決するために、Bamboo は以下のコンセプトを提供しています。
- デプロイ プロジェクト — デプロイするソフトウェア (Web アプリなど)、デプロイされたソフトウェアのリリース、およびライフサイクル全体を通じてデプロイされる環境を指します。
- 環境 — ソフトウェア リリースがデプロイされたサーバーまたはサーバー グループ、およびデプロイを円滑に機能させるために必要なタスクを指します。環境の例としては、開発、QA、ステージング、本番などがあります。環境には、誰が環境をデプロイ、編集、または表示できるかをきめ細かく制御し、さらにデプロイされたリリースの全履歴を記録することができる権限があります。
- リリース — アーティファクトとそれに関連付けられたデータ (コミット、JIRA 課題、テストに使用されたビルドなど) のスナップショットを特定します。リリースにはリリース自体と以前のリリースの違いに関する情報が含まれているため、リリース間の変更や、2 つの異なる環境にデプロイされたソフトウェア間の違いを容易に確認できます。リリースが、どの環境にデプロイされたかも追跡します。
デプロイ プロジェクトの仕組み
次の図を考えてみましょう。
On this page:
継続的なデリバリーとは?
継続的なデリバリーとは、ソフトウェア プロジェクトに加えられたすべての変更を自動的にビルドおよびテストし、ユーザーへのデプロイ準備を整えるプラクティスです。実際には、プロジェクトのビルドとテストが完了すると、手動で検証できる場所に「ステージング」され、ユーザーが利用できるようになります。
継続的デプロイ (コードの変更が人間の介在なしに自動的にビルド、テスト、デプロイされるプロセス) とは異なり、通常、ソフトウェアの品質が十分かどうか、または企業がユーザーに対してソフトウェアを利用可能にする正しいタイミングかどうかは、人間が判断します。
アーティファクト
ビルド計画でデプロイ可能なアーティファクトを作成してテストします。Bamboo でデプロイするアーティファクトには、環境のデプロイ手順で使用できるように、必ず「共有」としてフラグ付けしてください。
Releases
テストに成功したアーティファクトはリリースの作成に使用できます。リリースは好きな数だけ作成できます。Bamboo は、関連するコミットや JIRA 課題などのその他のメタデータを各リリースに追加します。これにより、各リリースが環境内を移動する様子をレポートおよび追跡できます。
Environments
Bamboo の環境は、IT インフラストラクチャの開発環境、テスト環境、および本番環境を反映しています。各環境のホスト名と認証資格情報は、デプロイ ジョブ内のタスクレベルにあります。どの時点でも、各環境でどのリリースが実行されているか、どのリリースに置き換えられたか、いつデプロイされたか、誰がデプロイしたかを確認できます。また、関連付けられた JIRA 課題も確認できます。
27 Comments
Graf
Jun 01, 2013Which variables are available in a deployment task? I'd like to get access to at least the deployment version.
James Dumay
Jun 26, 2013We are adding those variables soon. You can see what these will be in Variables for deployment environments.
Ray McDermott
Jun 24, 2013Can we integrate our Nexus Maven repo rather than using these shared artefacts?
James Dumay
Jun 26, 2013Hi Ray,
Not just yet but we've had a number of customers ask the same thing!
You can watch and vote for BAM-13345 - Getting issue details... STATUS which covers using artifacts from Nexus. It would be great if you could leave a comment and explain your use case (this helps us make sure all your needs are covered).
Thanks
James Dumay
Product Manager
William Gomes
Jul 16, 2013We already use bamboo build plans using Maven to build, release and deploy artifacts to a Maven repository. We then have separate plans to to deploy to our various environments. It would be nice to see more maven integration with bamboo, at the minimum BAM-13345 would be a good step in that direction to be able to pull released artifacts from Maven for deploys.
Patrick Wiltrout
Jul 20, 2013Is there any way to build a release from a plan branch? Currently I can only build releases off of the default branch.
James Dumay
Jul 24, 2013Not yet, but it is coming soon. See BAM-13268 - Getting issue details... STATUS
Łukasz Strzępek
Jul 24, 2013Why in deployment project I can't use MSBuild task?
James Dumay
Jul 24, 2013There were incompatible changes between the way that build tasks and deployment tasks work. The MSBuild task has not been brought across yet.
Please watch and vote for BAM-13515 - Getting issue details... STATUS
Mark Brodziak
Sept 03, 2013I like the new deployment project feature, but I have a few questions:
James Dumay
Sept 03, 2013Hi Mark,
Great questions. Let me try and answer them for you:
You might want to vote and watch for this issue that adds requirement support to Environments. We plan to deliver it shortly.
BAM-13499 - Getting issue details... STATUS
If the JDK is different for each environment, you should be able to set a variable for the JDK against the Environment. However, I can see a use case for parameterised deployments, so I have raised the following issue for you. If you can, please describe in detail on the issue your use case.
BAM-13707 - Getting issue details... STATUS
While I believe build and deployment blueprints/templates are ultimately what we should develop, in the short term we are adding the ability to Copy tasks from other Environments. Vote and watch for the issue below.
BAM-13269 - Getting issue details... STATUS
You mentioned you wish to "share" environments between projects - is this for configuration, reporting or both? I'd love to hear more about your thoughts here.
Thanks
James Dumay
Product Manager
user-055e6
Nov 21, 2013I also have interest in sharing environments. We have multiple projects and builds. Each build is then setup with its own deployment. Then each deployment has a dev, qa, and prod. But the 3 environments are all the same even though they are each defined separately in each of the deployments. It would be nice to share or link the environments so that I can click on an environment, say dev, and see all the projects deployed to that environment. Does that make sense?
James Dumay
Nov 21, 2013Thanks Patrick. You might be interested in voting for the following issue:
BAM-13575 - Getting issue details... STATUS
Anonymous
Sept 06, 2013Hi all, I'm wondering if it is a bug that I can't use a source repository in any deployment task. To be more specific I can add the task, but I'm not able to select any source repository because the combo box is empty.
Tomi
Feb 05, 2014Looks like you have to go into Bamboo Admin/Shared Repositories and define the repo there before they are available to deployment projects (unlike build projects where you can define the repo indepedently).
Telstra Automation Engineering
Sept 16, 2013We would like to use deployment plans for plans which don't produce any artifacts.
Our specific example is Puppet Manifests which we run a series of tests against before executing a Capistrano task to deploy to the Puppet master. In our deployment plan we just need to check out the source repository but like Anonymous above this doesn't seem to be possible.
user-d5d75
Sept 19, 2013In the current implementation it seems that parallel execution of the deployment tasks on mutiple agents is not possible. Selecting multiple agents as being dedicated to an environment will result in a round-robin single agent selection upon deployment.
We have multiple nodes in our production environment and would like to be able to have a "Production" environment definition which runs parallel deployments to multiple nodes. The task execution is identical for each node (even variables).
I can imagine something similar to the concept of stages in build jobs. For us this concept is also very suitable for the deployment projects.
Jordan Packer
Jan 09, 2014We have the exact same problem. We'd like to move all of our deployments into Deployment Projects, but that requires us to run everything one step at a time. For environments that require a deployment to multiple nodes, running in parallel decreases the deploy time by 80%. I don't know if we'll be able to use Deployment Projects until this is fixed.
James Dumay
Jan 10, 2014I've created an improvement for multiple node support however, we do not have plans to work on this today. Our recommended way of deploying to multiple nodes is to use an orchestration tool, such as Fab or Capistrano, to take care deployment to multiple nodes from the agent and have Bamboo kick off this process from a Script task defined on the environment.
BAM-14194 - Getting issue details... STATUS
Michael Dalzell
Sept 27, 2013Is it possible to deploy into an AWS environment contained in a VPN using this method?
Anonymous
Nov 12, 2013Is there a way to organize the deployment dashboard on a Project basis similar to Builds?
NathanA
Nov 13, 2013Hi, at the moment there is no way to filter deployment projects in the same way as builds are. If this is imprtant to you, please raise an issue and vote for it.
Thanks
David Zahorsky
Nov 14, 2013Well i really like the deployment plans.
We already integrated it with lot of success. But now comes the next step. Is it possible to run Tests on these Environments? Yeah i know i could launch a script which is testing these environments, but i would like to have the same Integration as it is on the build plans.
The problem is, that we can run tests "just" in the build plan. But now we want to add Selenium Tests on the different Environments.
Any plans on that? Or is my approach of thinking wrong?
James Dumay
Jan 10, 2014You can run tests from within environments today, however, you will not have any test reporting. Test reporting is something we are thinking about, so be sure to watch and vote for the issue below:
BAM-13276 - Getting issue details... STATUS
Anonymous
Jan 23, 2014First paragraph, you probably meant "QA, staging and productION environments"?
Anonymous
Feb 04, 2014It's a shame deployments are sequestered off into a different part of the program. It would flow very nicely if deployments could be a "Stage" of a larger plan. Like: 1) Checkout 2) Test 3) Deploy to test 4) Automated testing 5) Deploy to UAT
As it stands in order to use Deployment Projects, you can't get the above flow. You can accomplish the above if stages 3 + 5 are just normal stages but you lose the context of tracking deployables.
James Dumay
Feb 04, 2014This improvement which should satisfy your pipelining requirement
BAM-13347 - Getting issue details... STATUS