Answers: <p>I think you have fundamentally misunderstood the relationship between plans, stages and jobs in bamboo.</p>
  
  <p>A good rule of thumb is to have a single repository of code, which is linked to a single build plan, which produces a single independent module.</p>
  
  <p>You may initially start out creating a single stage with a single job inside each single plan where you just run a single maven command and the unit tests built into your maven build may be perfectly sufficient to exercise your modules completely in this extremely simple use case you probably don't need a tool like bamboo or Jenkins to deal with your builds.</p>
  
  <p>However, very quickly your conceptualisation of a "build" gets very complicated. As you mentioned in your question you might quickly amass multiple modules that are interrelated, or you might need to support your code on multiple platforms or in multiple browsers, and if you get all the way to the CD end of the work flow you might even need to deploy binaries into environments as the result of a code change.</p>
  
  <p>This is where you would want to use the extra orchestration capabilities of your CI tool.</p>
  
  <p>For example, if you are developing a module that you expect to load in a browser then your might have a build pipeline that looks like:</p>
  
  <p>Check in Code -> Build/Compile/Unit Test -> Deploy to a CI environment -> Stand up a half dozen browsers and verify that they all still work correctly.</p>
  
  <p>In the above work flow you would have a single stage to handle your compilation and unit testing which would spit out a compiled or built artifact. Then you have a stage that does whatever needs doing to make your module useful, ie it might create your final shippable product by combining your module with other modules built from other plans, or it might package some software into an RPM, a DEB and so on, depends what you're actually building. If you need to ship to multiple platforms then this is your first stage where parallelism becomes meaningful.</p>
  
  <p>Alternatively, if you are building for a single platform but for multiple consumers you might follow up this build of your component with a bunch of headless browsers kicking off test cases to validate that your changes didn't break anything. These can all happen in parallel on different agents running in different OS's, depends how you have bamboo configured.</p>
  
  <p>Then finally, assuming you are shopping something more complex than a single module, you will want to do a bit of integration testing with all the other components that you need to interact with. This step will usually be separated into a build plan of its own, triggered by the successful completion of the plans which are spitting out individual modules. Here you get a chance to run all the same tests but with your latest version running along side everyone else's module so you can be sure that there are no breakages caused by dependencies.</p>
  
  <p>So at any one time you only have a single repo triggering a single plan. If you have multiple repositories feeding into the same plan and they are completely unrelated but use the same build pipeline then I'd recommend taking advantage of bamboos plan branches so that you can reuse the same build process but with multiple different code bases (if that fits your use case)</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-05-31T08:28:33.830Z
Answers: thank you for this exhaustive elaboration; for the final part regarding the plan branches I need to understand - given completely unrelated repos A and B (but organized and built same way), you mean it's possible to branch same plan between them to reuse the build plan design? I though plan branches are thought to build branches of same codebase.
Answers: Ta Mu
Answers: CC BY-SA 3.0
Answers: 2017-05-31T17:05:48.710Z
Answers: It's possible to link different rapos up to the same plan and simple point at their respective branches. Behind the scenes they are just individually maintained build plans anyway. The ideal way to do it would be to give each repo and entry point plan which does whatever prep work I'd required and is unique to that repo but nothing else,  then have a child plan that is triggered by all those other plans which you can use as your common plan.
Answers: hvindin
Answers: CC BY-SA 3.0
Answers: 2017-05-24T17:42:52.110Z
Answers: 2017-05-24T17:42:52.110Z
Answers: hvindin
Body: <p>Imagine the following setup: a build plan has a set of jobs (J), each builds a module (M). Latest successful build for all of them is also there. (BX)
  E.g. (imagine there are ten or so; modules are interchangeable i.e. will be never linked to each other)</p>
  
  <pre><code>J1-&gt;M1-&gt;BM1-X
  J2-&gt;M2-&gt;BM2-Y
  J3-&gt;M3-&gt;BM3-Z
  </code></pre>
  
  <p>Now imagine there are changes in just one of repos, say M1. We know that Bamboo runs jobs in parallel.</p>
  
  <p>Questions:</p>
  
  <ul>
  <li>will Bamboo completely rerun builds also J2 and J3, even if it finds out there are no changes in repos M2 and M3?</li>
  <li>If yes (I think so by a test setup but not sure), what is the purpose of doing so? (at least in terms of Bamboo logic)</li>
  </ul>
  
Tags: <bamboo>
Title: Rerun of Bamboo jobs on commit
UserDisplayName: Ta Mu
ThreadText: # Rerun of Bamboo jobs on commit
  
  (Asked by: username_0 on 2017-05-17)
  
  Imagine the following setup: a build plan has a set of jobs (J), each builds a module (M). Latest successful build for all of them is also there. (BX)
  E.g. (imagine there are ten or so; modules are interchangeable i.e. will be never linked to each other)
  
  ```
  J1->M1->BM1-X
  J2->M2->BM2-Y
  J3->M3->BM3-Z
  
  ```
  
  Now imagine there are changes in just one of repos, say M1. We know that Bamboo runs jobs in parallel.
  
  Questions:
  
  * will Bamboo completely rerun builds also J2 and J3, even if it finds out there are no changes in repos M2 and M3?
  * If yes (I think so by a test setup but not sure), what is the purpose of doing so? (at least in terms of Bamboo logic)
  
  **Tags:** bamboo
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2017-05-24. Score: 3 | Accepted answer
  
  I think you have fundamentally misunderstood the relationship between plans, stages and jobs in bamboo.
  
  A good rule of thumb is to have a single repository of code, which is linked to a single build plan, which produces a single independent module.
  
  You may initially start out creating a single stage with a single job inside each single plan where you just run a single maven command and the unit tests built into your maven build may be perfectly sufficient to exercise your modules completely in this extremely simple use case you probably don't need a tool like bamboo or Jenkins to deal with your builds.
  
  However, very quickly your conceptualisation of a "build" gets very complicated. As you mentioned in your question you might quickly amass multiple modules that are interrelated, or you might need to support your code on multiple platforms or in multiple browsers, and if you get all the way to the CD end of the work flow you might even need to deploy binaries into environments as the result of a code change.
  
  This is where you would want to use the extra orchestration capabilities of your CI tool.
  
  For example, if you are developing a module that you expect to load in a browser then your might have a build pipeline that looks like:
  
  Check in Code -> Build/Compile/Unit Test -> Deploy to a CI environment -> Stand up a half dozen browsers and verify that they all still work correctly.
  
  In the above work flow you would have a single stage to handle your compilation and unit testing which would spit out a compiled or built artifact. Then you have a stage that does whatever needs doing to make your module useful, ie it might create your final shippable product by combining your module with other modules built from other plans, or it might package some software into an RPM, a DEB and so on, depends what you're actually building. If you need to ship to multiple platforms then this is your first stage where parallelism becomes meaningful.
  
  Alternatively, if you are building for a single platform but for multiple consumers you might follow up this build of your component with a bunch of headless browsers kicking off test cases to validate that your changes didn't break anything. These can all happen in parallel on different agents running in different OS's, depends how you have bamboo configured.
  
  Then finally, assuming you are shopping something more complex than a single module, you will want to do a bit of integration testing with all the other components that you need to interact with. This step will usually be separated into a build plan of its own, triggered by the successful completion of the plans which are spitting out individual modules. Here you get a chance to run all the same tests but with your latest version running along side everyone else's module so you can be sure that there are no breakages caused by dependencies.
  
  So at any one time you only have a single repo triggering a single plan. If you have multiple repositories feeding into the same plan and they are completely unrelated but use the same build pipeline then I'd recommend taking advantage of bamboos plan branches so that you can reuse the same build process but with multiple different code bases (if that fits your use case)
  
  > **Comments:**
  > **username_0**: thank you for this exhaustive elaboration; for the final part regarding the plan branches I need to understand - given completely unrelated repos A and B (but organized and built same way), you mean it's possible to branch same plan between them to reuse the build plan design? I though plan branches are thought to build branches of same codebase.  
  > **username_1**: It's possible to link different rapos up to the same plan and simple point at their respective branches. Behind the scenes they are just individually maintained build plans anyway. The ideal way to do it would be to give each repo and entry point plan which does whatever prep work I'd required and is unique to that repo but nothing else,  then have a child plan that is triggered by all those other plans which you can use as your common plan.  
  
  ---
  
  