Moving code to different environments - workflow or reassigning tasks

[Crystal Gunter]

We need to push code to different environments and then test the deployment. We have 4 environments - Dev, Test, Stage, Prod. After code is pushed to Test, it needs reviewed and then pushed to Stage, reviewed and then pushed to Prod. Should I set this up as a workflow? I tried that originally and it got pretty complex. I eventually gave up as I didn't know if that was the best solution. Basically, I need to know what code has been pushed to what environment. What is the best way to handle this?

[David Berclaz]

Hi @Crystal Gunter

In order to track the versions deployed on your different environments, you can use the Apwide Golive Jira app. You will be able to:

• Manage your Environments Inventory
• Book and Schedule activites on those environments
• Manage your Deployments and even trigger them from Jira
• Get some new Reporting Gadgets for your Jira Dashboards

There are also some more advanced DevOps use cases, like the possibility to setup an Environment Self-service in order to trigger the provisioning of new Environments from Jira.

Hope it helps, let me know sould you need more info.

Cheers,

David

[Raymond Lai]

Hi Crystal,

I would absolutely recommend getting this process set up as a workflow. Our organization has a similar process for one of our developer queues where code goes from one environment to the next.

The basic setup is to create a workflow where each environment would correspond to a particular status. When a ticket moves from status to status, it signifies the movement from one environment to the next. You can create additional statuses in between to capture your org's special tasks before a bug gets moved from state to state. For example:

State0: In Dev Environment (Workflow options: Code complete, push to test)

State1: In Test Environment (Workflow options: Test complete. Push to Staging)

State2: In Staging (Workflow options: Push to Code Review)

State3: Under Code Review (Workflow options: Fail code review, Pass code review)

State4: Ready for Production Scheduling (Workflow options: Push to prod)

State5: In Production

You can insert additional states to capture any custom processes you may have, but the above would be a good start.

In terms of capturing the code changes, there are several options available to you:

0. Create a custom field called "Code Change", and ask your developers to add their code in the field. This is easy to implement, but developers hate this because it's not efficient, and doesn't capture code deletions to make the code change

1. A combination of Atlassian dev tools with JIRA integrations would be useful. Fisheye works great with JIRA since it's a native integration. There are methods to link JIRA issues with Fisheye code changes. There's a nice guide in the wiki: http://confluence.atlassian.com/display/JIRA/Integrating+JIRA+with+FishEye

2. If you're using continous integration using Hudson, there's a nice JIRA plugin that updates tickets automatically with each build.

I'm not the best expert integrating code info, but workflows are my speciality. Post a reply if you would like more elaboration.

[Mark_Stray]

Hi,

I am new to JIRA  and would like to use it for change management.

My question is around what to do for changes that move from DEV to TEST to PROD.

Should this be 3 separate Change requests (1 for each) or one change with considerable workflow design to enable all changes to be handled from the 1 request.

regards