Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,461,960
Community Members
 
Community Events
176
Community Groups

How do you manage the development of your Jira instance?

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?

1 comment

There are a couple of things I would be doing here.

First, I usually have a Jira project to keep all the requests for new and changed apps, projects, fields and so-on.  In some cases, I even wrote scripts to do some parts of the requests automatically.

More important to this question though is that your user-story is exactly what lead Botron to write Configuration Manager, Pepe to write Project Configurator, and some others (that I haven't used or met the authors of, so struggle to name).  They needed to do config in dev/staging and then push it to production automatically.  

Like Penn likes this

@Nic Brough -Adaptavist- Thank you! We've worked with Project Configurator. That helped when we were building new projects in DEV and pushing to PROD. I did not know about Configuration Manager and this might be exactly what we're looking for!

Comment

Log in or Sign up to comment