Does a Bamboo Spec Java Plan know which Linked Repo caused an automated Build and Deploy

[Michael Smith]

Essentially, I was thinking of creating a different project based on whether the Repo was pointing to master or to a feature branch.  That way branches did not mess up the main project, but maybe a sandbox project instead.  Any ideas or thoughts would be great.

[Daniel Santos]

Hello @Michael Smith

If you are mainly referring to deployments, I want to make sure you know that they essentially only happen to the specific branch configured in them. What I mean is that even if you have multiple plan branches with new builds, there is only one build automatically driving the deployment itself.

Does that make sense to you or there is something else I'm not seeing clearly from your explanation?

When you say deploy, are you using the Bamboo deployment project or are you just using builds to deploy your changes?

[Michael Smith]

Constraints / Assumptions:

• I am currently not talking about Bamboo Deployments in any capacity.
• My concerns are with Automatic Scanning of Bamboo Specs in a Linked Repo setting.
• Assume we have one project called "DevOps" and all plans are considered Production Plans, and should only be modified after testing new features.
• When referring to my one project or Bamboo, I will use the term "Bamboo Production Environment" to refer to what is on master and what everyone in the dev team will be using.
• This Project DevOps was created via Bamboo Spec Linked Repo on commit to master.
• I want to create a new branch called "staging/msmith", and setup a Linked Repo with that particular branch name.  I also want to enable Bamboo Spec on commit in this Repo as well.

Now my question is can I dynamically know during the runtime of my Java Bamboo Spec code that I am running off a commit that was committed to staging/msmith?  If I did know this dynamically.  I could then make my code create an alternate project called "DevOps (Sandbox - msmith)" in which all five plans exist, but in this alternate Project, and hence Bamboo Production Environment would not be touched.  Then when I am satisfied with the changes on my branch, I can do a pull request, have my peers review it, and then merge it to master, where it will now be the new Bamboo Production Environment.

I am trying to understand if Bamboo Specs at runtime has an knowledge of what commit launched it, and how to get that info.  If it knows the commit or linked repo can I get the name of these objects in some way?

[Daniel Santos]

Thank you for the whole explanation. I think I now understand what you are talking about. I would say the answer is no, but I'll try to get a developer to review this question and check if he can give us a way to handle that.

[Daniel Santos]

For some reason, I forgot to update this one, sorry about that. I was able to talk to a developer about this and he shared that this is not possible considering how Bamboo is designed at the moment.

[Michael Smith]

Daniel,

Do you think we could write up a new ticket around providing this information through argv in Java in the future.  It would be nice to somehow access this type of information from Bamboo Specs Java Code to make informed decisions.

I guess as another question how do you anticipate people trying to stage in Bamboo Spec?  Do you see them using a separate branch that is talking to a sandbox Bamboo Server?  Then fixing there problems there?  How do you deal with remote agents needing to be the same for production Bamboo Server and sandbox Bamboo Server?  These are probably broader topics, but I was wondering if there were a best practices for staging new development work in Bamboo Specs to prevent pushing bad code to Production.

[Daniel Santos]

Hello Michael,

Do you think we could write up a new ticket around providing this information through argv in Java in the future. It would be nice to somehow access this type of information from Bamboo Specs Java Code to make informed decisions.

I guess I need to step back a little bit. I was thinking on how to write this feature request and I realized that was not understanding your issue from the first place.

Let me share what I understand now and how I think we can handle the questions you have.

I think your main concern is how to stage your plan configuration changes. How you could validate your configuration and then deploy it to production when it is ready.

First of all, I want to clarify that Java specs run on a specific branch configured in your linked repository. It will only automatically configure plans based in commits arriving in that specific branch. It means that if you want a different branch to create plans using specs you will need to create another linked repository entry and configure it with a different source branch. I guess that will also be a solution for you in terms of what plans will be affected when a commit arrives in Java specs repository branch.

I guess as another question how do you anticipate people trying to stage in Bamboo Spec? Do you see them using a separate branch that is talking to a sandbox Bamboo Server? Then fixing there problems there?

I don't have access to historical data on how users are doing this process neither best practices on this since this feature is fairly new. I believe you could create another linked repository for your branch and keep a different code when referring to plan names/plan keys. The source repository would be the same, but with two different linked repositories, each one triggering different plans. That would allow you to merge the code from branch to master when that code is validated.

How do you deal with remote agents needing to be the same for production Bamboo Server and sandbox Bamboo Server?

I would try approaching this problem by creating different requirements for production and staging or even dedicating an agent to the plan responsible to run the staging environment. The would prevent this plan to try using agents from production and vice-versa.

These are probably broader topics, but I was wondering if there were the best practices for staging new development work in Bamboo Specs to prevent pushing bad code to Production.

They are important points which deserve the right attention. I just don't have any reference for you on best practices at the moment.

Please read what I shared and challenge me so we can be on the same page and then decide if we need to file a feature request and how this would look like.

I'll wait for your comments.