I'm having different project structure in each branch, is it possible configure different jobs/ tasks for each branch in bamboo? If not please suggest me any alternatives.
It's not possible to configure different tasks per branch in Bamboo. I can suggest 2 alternative ways:
You can use branch "Variables", use the Script task and have different manipulations based on the branch variable.
And if your project structure is really different per branch, I would suggest you to create a new plan for it.
Related
I use bamboo specs to backup my plans in bamboo. However, if I remove one plan and restore it back, all the branches created for this plan are missing.
I tried to use this API endpoint Enable specs for branches but it does not seem to do any effect.
Is there any way to get the configurations and variables related to the branches of a plan in specs?
So then, if we restore back a plan that has been removed, there's no need to create branches manually and set up all needed variables specific of each branch.
I have inherited a collection of Bamboo build plans and corresponding deployment projects. Here is a particular example of how I would like to leverage reuse. We a four deployment projects (say ProjA, ProjB, ProjC, ProjD) that can be run individually/independently. However, we also have a project where we deploy them together (call it ProjABCD). Currently, ProjABCD replicates the steps from the individual A, B, C, D projects and executes them consecutively (e.g., if each has 10 steps, ProjABCD has 40 steps).
Is there a way to have a super-project (ProjABCD) that simply simply "calls" the four individual ProjA, ProjB, ProjC, ProjD? Ideally, this would also be able to roll-back to baseline state if any project in the group fails to deploy properly.
You should be able to come up with a scheme using the triggers functionality. There should not be a need to have a 40 step combined deployment (that breaks a lot of the value the deployments provide). There are multiple ways to solve/simplify this problem. For example you may choose to have two different builds, and only one of them triggers the 4 deployments.
When creating a plan branch, is there a way to configure Bamboo to make new branch when a pull request is created and in addition, for a set of branches that match a custom regex?
So it would be a combination of 2nd and 4th option
Using the Microsoft Project VSTO, I am able to iterate through all the Tasks in a project.
The problem with this approach is that if a file has one master project and multiple subprojects, the Tasks collection for the master project will contain tasks from ALL the projects (master as well as subprojects).
Is there someway to differentiate whether the Task is from a master project or a subproject?
The easies way is Task.Project that will return you name of a project your task belongs to link also you can get name of a subproject from it's "ancor" task in your master through Task.Subproject link. There is also a field which tells you if the subproject is Read-Only or you can update it: Task.SubProjectReadOnly link
If you want to access only the main project, it might be quicker to start with the summary task and recursively deal with each task's children, stopping the recursion on tasks which represent external subprojects. That way, you will not have to touch every task.
We are going to swap to Mercurial.
A piece in our plan that is missing is how to manage branching/merging of build to Test Box (and LiveBox) so isolated features can be mixed with the StableRelease and built to TestBox.
For instance, it seems the predominant usage is to have
DefaultStableBanch
TestBanch
FeatureABranch
FeatureBBranch
Development on FeatureA and FeatureB, will happen at the same time. It looks like predominant usage is to have cloned repositories with branches for the above.
Scenario 1 : If we build to test, we would merge LiveCode+FeatureA+FeatureB. If all goes well then we can merge the changesets to upstream to DefaultStable branch and build to LiveBox with FeatureA and FeatureB. job done.
Scenario 2 : If we build to test, we would merge LiveCode+FeatureA+FeatureB, and QA shows there is a problem with FeatureB. We do not want to build FeatureB anymore. We do want to progress FeatureA. We want to re-test with FeatureA on it's own and let QA pass that. Then release that to Live and hence business agility.
Questions :
If FeatureB fails QA , we need to take out FeatureB changeset nodes from the Test Branch, build to TesBox again and then hopefully then merge upstream to DefaultStable branch to LiveBox.
What is the best way of removing the FeatureB changeset nodes, from the TestBranch, since 1. we need more dev on FeatureB, and the FeatureB nodeset is not finsihed.
2. We need to isolate DefaultStable+FeatureABranch and build that to test
How are other people managing this ?
There are a lot of great writeups up Mercurial workflows, including:
http://stevelosh.com/blog/2010/02/mercurial-workflows-branch-as-needed/
http://stevelosh.com/blog/2010/05/mercurial-workflows-stable-default/
https://www.mercurial-scm.org/wiki/StandardBranching
All of those use Named Branches very minimally -- definitely not one per feature, which with clones as branches sounds like the work mode you (and I) prefer.
Hitting your specific question, if the combination LiveCode+FeatureA+FeatureB is failing tests the the best way to handle it is to just keep repairing FeatureB and then merging those changes down into FeatureA + Feature B. However, before you get to that stage it's a good idea to have QA hit LiveCode+FeatureA and LiveCode+FeatureB separately too, it's slightly more work for them (more test targets) but having each feature in isolation helps find the cause of the defect more quickly.
Once LiveCode+FeatureA and LiveCode+FeatureB are passing QA, then you merge them into LiveCode+FeatureA+FeatureB and if that still passes tests merge the whole thing into DefaultStable. There should be no need to remove FeatureB from a LiveCode+FeatureA+FeatureB because you can always just create a new clone of LiveCode and merge in only FeatureA if you want it.
Here's a great writeup of a Mercurial (Kiln) based QA/release process:
http://blog.bitquabit.com/2011/03/10/when-things-go-well/
Create FeatureA and FeatureB in feature clone branches from stable. Test is merely a temporary area for QA/Test to work from, so I would treat it as 'throwaway' from day one.
When FeatureA and FeatureB are developed enough, create a clone of either one, and pull the other into QA/Test. Do the build for QA, and when they provide feedback, make appropriate changes to FeatureB.
If FeatureA is acceptable for promotion, pull it into/push it to Stable, and merge into stable.
Is that clearer than my original post?