You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Join now to unlock these features and more
We are migrating legacy applications to our Jira instance which focuses mainly on business decisions. The initial project went well and we continue to add projects. Some projects interlink, others are standalone. The teams are getting feature requests for our Jira projects involving workflow changes, field tweaks, etc.
We leverage a large selection of plugins, including ScriptRunner, Better PDF Exporter, and Jira Workflow Toolbox. Sometimes the change requests require some tweaking and testing which if done correctly could adversely impact our production systems.
We are challenged with the best practice for developing changes to production Jira projects. We can develop our solutions in our dev environment but then we still need to migrate changes to production. This is a manual process as well.
Overall, managing development requirements and change requests for Jira projects seems awkward and very unlike developing software. It is not the "Fork a branch -> Code -> Test -> Publish -> Merge Request". Instead, as far as I know, its "Build in dev -> Test -> Manually Migrate to Production." In single instance changes this isn't too bad but if I've got multiple changes in multiple projects, I have to remember each detailed change and make them in production.
Is there a better way?
tl;dr - Changes to production Jira projects are awkward and can cause issues. What's the best practice for developing changes in projects, workflows, plugins, scripts for Jira and pushing to production?