Bamboo: Plan reuse between diferents projects

[Sebastian Perrone]

Hi, we are a java development team working in a small company (10 people, including 4 administrative ones) and we are evaluating Bamboo. Ours project are managed via Maven 3. We include some of these projects in a trial Bamboo and we realized that to generate jobs and plans of each project we repeated the same parameterization. Ie equivalent tasks in equivalents jobs on equivalents plans, the only difference between projects is the URL of the SVN repository. Is there
a way to do this by defining a plan to share between projects ? or job sharing between project plans? If it exists a way, how? and how this job would be counted in the licensing?
Our question is motivated by the possibility of using Bamboo starter license on our developments, but parameterizing only some of our projects have far exceeded the 10 jobs...

[Sultan Maiyaki · Accepted solution]

Hi Sebastian,

I understand that yoy are faced with the issue of job limitation and looking for a way not to use all the 10 jobs limit. In this case, I will suggest the following options and will like to point our that plan branches also inherit the jobs or have their own defined jobs that will count towards the license. Also there is not feature to share a job:

# Since each job can have an unlimitted number of tasks, you can decide to have a single plan with a single job that has several tasks for each of the java project. This you will have to do with careful design

# You can create a single plan with 10 repos for each of the projects and the checkout task with then clone each repo in a subdirectory. You can then use tasks to manipuate and build each of the sub directory as needed

# This might not be convinient but you can always disable and enable job in case you run in to more than 10 jobs

Hope tha helps

Regards,
Sultan

[Sebastian Perrone]

ok, thank you very much, we will present your advice

[Sultan Maiyaki]

You are most welcome Sebastian

[Alok Singh]

How do you control checking out of all the 10 repos? Let say there was a change in one of the repo and it triggered a build it then it first checks out all the 10 repos then identifies where actually the change happened.

[Ellen Feaheny [AppFusions]]

Have you looked at Plan Branches -

https://confluence.atlassian.com/display/BAMBOO/Using+plan+branches

Here's a good blog:

http://blogs.atlassian.com/2012/08/bamboo-4-2-git-branches-jira-issues/

On licensing, review this:

http://www.atlassian.com/licensing/bamboo#downloadlicenses-6

[Sebastian Perrone]

We use the branches according to the standard SVN. That is, we generate branches on specific versions of our products according to the demand of corrections that arise in its use. Fix the issue with an external agent would be feasible but also understand that it would face the solution externally. If not, exists an example ? or a study case ?
I certainly not asked the question correctly, so I do it again in a different way:
Small businesses (like us) and freelance developers that moderately structured source code, quickly reaching develop 10 jars (thinking about developing with java). We understand that for every java project that is imported to Bamboo, necesarily generates a plan and a job, so quickly exceed 10 jobs, although the 10 plans are the same, so also the 10 jobs. For example, we have the following java projects:

• entity-1.0.4
• dao-2.0.7
• hibernatedao-1.0.12
• mappingdao-1.1.24
• ibatisdao-1.0.3

Each of them is a project itself, which we used as tools in the developments that our clients hire us. The continuous integrationwe aim to perform on each stem primarily from maven (test, pmd and javadoc) and an additional verification of the structure of the pom.xml (we have a shell script to do that).

Therefore, the question that the checks being conducted on each of our projects are similar: it is necessary to define 10 plans and 10 jobs ? is possible to define a single plan with a single job to be shared among different projects. Thus the limitation of 10 jobs from the starter license imply 10 different ways of testing, we believe most appropriate limit for small companies or freelance developers.

Are we missing something ?

Thanks anyway.

[john_wojner]

(*answer is on bottom*)

This is way late, but I was looking for something similar. Though I have hundreds of plans, so my solution doesn't really work for me. I would like to see something like sharing stages/plan configurations between different plans. For example, I have a generic stage used in multiple plans, if I change that stage it changes for all plans. Another better example, I have a plan setup that is used the same across the same project and is very similar to multiple other projects. I would like to inherit the single plan setup for each project, therefor changing the generic plan would change for all projects. Then we would have a derived plan, where changing the parent plan would change only the dependent plans. So I could have very similar setup for multiple projects, change something only in one place and that change is used for any project using it, and finally would be able to change a plan derived from the generic plan, so that the derived plan has the changes from the generic, but any changes to the derived plan will not affect all of the generic plans... but it would affect any plan that either uses that derived plan or is a child of that derived plan.

As for your problem, since your limited by number of projects etc, what you can do is use one plan and have a bunch of different tasks for all the different projects you want in your CI pipeline. Make the tasks non-fatal failures so that each project will run with the given task. Its super easy to clone a task or create a template task you can use, so you can do that and just change what repository its actually using. There are of-course some nuances, but nothing too difficult to figure out.

Regards

[john_wojner]

***Edit***

Sorry, I just re-read your post.

I'm not sure if you mean 10 jobs or 10 plans for different ways to test, but you need neither. You can just define a single job in one plan that does all of the tests in one run. If you need test parsing thats fine, just don't parse the test results until the very end (which normally it does on its own, but if you have xslt transformations or something of the sort to get the test results in a bamboo-parsable format then for those you can just transform after the run and do the test result parsing in a final task later on)