Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Using CI for continuous delivery Part 3


Published on

This is part 3 of "Using CI for continuous delivery" in which we test drive Bamboo. More details can be found at

Published in: Technology, Business
  • Login to see the comments

Using CI for continuous delivery Part 3

  1. 1. Bamboo ftware/bamboo
  2. 2. Bamboo has two separate Build and Deploy sections, sounds promising eh? Let’s get started with a “build” pipeline..
  3. 3. For a “Build plan” we can configure triggers, branches, dependencies etc. Within “Build plan”- there are stages, which can have jobs and jobs can have multiple tasks
  4. 4. Standard set of tasks available in Bamboo Hierarchy in Bamboo Source: Bamboo Website We have sequenced some tasks to get a job done in first stage of pipeline
  5. 5. For this jobrequirements are JDK and Maven – which are clearly called out! You can add more too..
  6. 6. Ran a build successfully!
  7. 7. Result of build can be associated with an “artifact” for future use
  8. 8. Overall view of past builds etc.
  9. 9. From a “build” pipeline you can create a deployment project/pipeline
  10. 10. For deployment project you can configure versioning (Release 1-n), permissions (Who can deploy?) and the target environment As we added tasks previously – we can add tasks like “deploy to tomcat” etc.
  11. 11. So we have our “dev” deploy pipeline- set to automatically trigger by build pipeline (See Triggers-1?) and deployment pipeline defined. The QA deploy pipeline has a manual gate which we will see later
  12. 12. Let’s create a release from the Dev pipeline template and run it. When the deploy pipeline is triggered by build – then a release is created automatically
  13. 13. Final confirmation screen of release – before you hit “Deploy!” Shows all relevant info
  14. 14. And here we have a successful release!
  15. 15. Release history for a given release including which branch it came from Notice some build were kicked off manually but this one was auto triggered by build job!
  16. 16. All deployment pipelines overview! For release-9 – it is in Dev but was never deployed in QA and QA is at Release-6 currently Valuable info isn’t it? Moreover you see commits tested by release9!!
  17. 17. When we deploy R-9 to QA – it shows all changes since last release We loved overall product – it’s understanding of semantics and right information at right place! And you can always compare what is “delta” between releases – without having to go through all commits!!
  18. 18. So we have jumped from R-6 to R-9 in QA while those releases were deployed in Dev!
  19. 19. Fine grained permissions as to who can access, create and deploy plans! Developer can build and deploy in Dev, Lead can deploy in QA and so on…
  20. 20. And Market has many more plugins – free and paid! Plus you can write your own
  21. 21. Bamboo- Concluding thoughts • Excellent support for CI as well CD semantics • Simple to use, valuable information at each stage. Overall traceability is excellent • Plenty of actions available OOTB and more can be added • Complex workflow support was excellent in “Build pipeline” but not so much in “Deploy pipelines”