I want to make sure I understand this properly.
I'm in the same boat. I have something like fifteen projects some with two environments some with three and each does exactly the same thing except it goes to a different server or a different path.
Now that I think about it it might be a better choice to create a single script (for each task or set of tasks as appropriate) and pass in the server name/path (or whatever the variables are) rather than duplicate each script to run them inline. That way you could create a single batch file, pass in the differing variable as an argument in each script and have lots fewer scripts to maintain.
*headdesk* (just updated twelve different projects this morning for every environment). *dies*
Me writing out my question actually gave me a lot of insight into the process. Its exactly like i wrote it out. So i guess this is me answering mysefl saying "yes".. Basically make build plans create artifacts, and let deploymet projects do teh rest of the work.
However, to answer your question: don't write scripts. Instead you should duplicate your work for each slightly different environment (its a pain in the butt, but just sit down and get it over with), that way you retain the main benefit of deployment scripts which is "what jira issues are fixed where and what release versions were deployed where, by whom and when".
There is a JIRA issue with atlassian to have "clone" enabled for deployment projects, we just have to wait for it to be ready.
You always write scripts, the distinction I meant to make was instead of using a bamboo script task in your bamboo job, that uses an inline script repeated slightly differently for each project/env create a bamboo script task that calls one single script, that is repositoried of course, stored on your server in a common location (I have a scripts folder under bamboo that I use for this purpose) and called as an external script in your bamboo script task, passing in the variables for the project/env.
Both achieve the same result of being included with your bamboo build, the benefit of a single script is obviously maintainability. Both are called as tasks in your build job (or deployment job in this case) both are included in your build log (as long as you are echoing output from your external script.) You lose nothing by having an external script with a bamboo script task. You gain reuse and maintainability.
As soon as you click build in bamboo, and you retrieve your source from your repository regardless of what tasks you have in your build job any related JIRA issues are already associated to the build.
I have Bamboo as basically a workflow manager. It will poll the repo for changes and start a workflow. Each checkout have a manifest file which tells my script/program what to build and stores the output in a folder I called Deployables which becomes my artifact. I currently have 77 plans with identical Stages, Jobs, & Tasks they only difference is the repo location because the difference between the plans is all in the repository/checkout; this also allows configuration changes to exist in branches and give some control back to developers (3 plans are protected with repo permissions on the manifest file).
My deployments are the same way, I have 2 environments on each deployment project "Functional" & "Q/A"; we haven't handed over production to Bamboo yet. The only difference between the two is the environment name and Functional has a trigger of plan success; everything is handled through variables and scripts including the Enivornment name. Our Functional "Enivornment" actually deploys to 31 different sites and our Q/A "Environment" actually deploys to 6 sites and it's all setup in scripts (and a DB for branch complexities with defaults and XR overrides). I can setup a new plan with deployment project in about a minute or I can add/delete an site from the lists in a matter of seconds. I can change the scripts to include a new deployable type of a full additional programming language and I only change it once. Variables and scripts are good, they provide modularity.
The build process should include everything that deals with transforming code into assembly, for runtime stuff like PHP this is nothing but a checkout and artifact.
The deployment should take over and include any type of environment specific changes whether it be configuration, signing, permissions, etc; ideally there is little but that is rarely the truth. Then it should actually take care of the deployment/installation.
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
👋Community members! Downtime happens. And great incident response takes a village. Teams like Support, Dev, SRE, Ops, IT, and Marketing have to come together to resolve the problem while keep...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs