Is there a recommended workflow for testing changes to Bamboo plans prior to production rollout?
We have a CI setup where we build our software and perform unit and integration testing. The configuration of our plans and associated scripts remains fluid and changes are frequent, so we often have a need to informally test out changes prior to rollout to production.
We do leverage JUnit to test the portion of our plans defined using Java (configuration-as-code). That works well for catching those types of early problems. However, I would describe the rest of our current workflow as both clunky and quirky. Right now we use what we call "sandbox" projects. Whenever we need to make a change we branch our Java code, modify it to refer to one of our Bamboo sandbox projects (rather than our production project), and point the branch field of the linked repository corresponding to that sandbox project to the config specs branch. For the most part this works fine but we have seen issues where on rare occasions jobs in our production plans get disabled or disappear entirely, even though they remain enabled in the Java code.
Both our production and sandbox projects exist in our PROD instance of Bamboo. We have discussed with our IT department the possibility of using our DEV instance of Bamboo to test changes but that would require granting our DEV instance of Bamboo access to our PROD instance of Bitbucket (where our Java config specs are stored), which they are reluctant to do.
Any tips?! We'd love to hear how others test changes to plans prior to rollout, or if Atlassian has any recommendations or pointers to something we may have missed. Thanks!
