I'm trying to put together a branching and deployment management strategy for managing a large number > 100 small applications that share a similar codebase.
The general situation is that we have a single template application that we customize and deploy for each of our customers. The development workflow is: 1) clone the template as new instance of code, 2) make the changes, 3) deploy instance to a subfolder on a web server.
I'd like to configure a workflow in Bitbucket and Bamboo to streamline our process. An ideal scenario would involve creating a branch (or better yet a fork) in Git, which would then trigger Bamboo to create a build/deploy plan for that particular instance of the template. We can sort of do this out of the box by treating each instance as a branch of the master template, and then creating feature branches off that, but I can't see a way to customize the workflow enough so as to enforce a naming convention when any of those sub-branches is then branched again - for instance for a feature or bug fix.
Any thoughts are appreciated on how to customize this complex workflow.
Hi @christok
With the constraints you shared, the only way I could imagine this environment working is by configuring something like:
I think the configuration above will allow you to have a different plan for each app. With that, you should be able to create any deployment projects you want pointing to each of your plans.
The only thing you will lose here is the ability to auto-create your Bamboo plan branches when a new source branch is created.
In this configuration, you will also be able to build the same branch in multiple plans in case you need it.
Thanks for taking the time to respond... we considered the workflow you describe here but ultimately we still wind up with multiple repositories and build plans, which is what we are trying to avoid.
What we settled on was a scenario in which the template exists as the master branch, and all instances are tracked as separate branches using the convention instance/{instance-name}. This gets us a separate plan branch every time an instance is created, and new feature branches each time an instance branch is further created.
Moreover, we can use bamboo variables to deploy each branch to the correct folder on our server. The only thing we don't have in this scenario is an easy way to see which feature release is currently deployed in which environment (since bamboo thinks of the whole thing as one big application, rather than a bunch of little ones) but I'm going to see what I can come up with in order to get us past that limitation.
This was actually pretty easy to put together once I had it in my mind. We were even able to script the migration from our old repo so we did't have to set up all the feature branches manually.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That is great @christok. Glad you could find a way to configure it.
Regarding the deployment, do you use a deployment project or do you use just the plan build to deploy your apps?
I ask that because in the deployment project you automatically deploy just one branch, but you can manually deploy any branch.
In case you need multiple branches do deploy automatically using a deployment project you would need to configure multiple of them pointing to the same plan.
I'm sharing some thoughts since I don't have a clear scenario of how you are running this process today.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
We are using a deployment project with manual deployment. This is fine because we deploy all our software manually beyond the deployment environment.
I think this solution works quite well for our needs. The only limitation really is the lack of ability to get a clear picture of which build of which branch is deployed to a given environment.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for sharing.
The following variables are available during the deployment runtime and should help you with this:
Example of content:
bamboo_buildKey=COM-AST-JOB1
bamboo_buildNumber=58
bamboo_buildResultKey=COM-AST-JOB1-58
bamboo_planRepository_1_branch=master
bamboo_planRepository_1_branchDisplayName=master
I hope that helps!
You can check all the variables available in your environment result logs or in this document: Bamboo variables - Atlassian Documentation.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.