Three stages in detail

Promoting Jira configuration from development to production

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

The procedure of staging any changes before they are made on the production server is a recommended IT best practice. The following article describes how to set up such environments: Establishing staging server environments for Jira applications. 

Steps

This use case has two major phases: promotion from test to staging and promotion from staging to production.

Test to staging

1. Test: Create all required changes to project A.
2. Test: Create a snapshot for project A.
3. Staging: (optional) Create a system snapshot for backup.
4. Staging: Deploy the snapshot.

    1. Use the Project Merge mode.
    2. Review the change and impact analysis in the Analyze step of the deployment.
      Now that staging is a close or identical replica of the production, during this analysis, you will see how the deployed configuration will impact the production server.
    3. Proceed with the deploy (the change and impact analysis shows that everything is OK.)
    4. Review the Audit log for any warnings.
    5. Test the deployed changes – the actual testing depends on the changes and may include creating issues, exercising issues workflow, etc.
      Declare SUCCESS/FAILURE – if the deployment and testing are successful proceed with promotion to production
    6. In case of failure, locate the error and make changes in the test environment to address it.

       
      Note – do not make changes directly to the staging server – it needs to remain the same as production.
    7. In case of failure, restore at the staging server the system snapshot created at step 3 above.

Staging to production

5. Staging: Create a snapshot of project A.
6. Production:(optional) Create a system snapshot for backup.
7. Production: (optional) Limit the user access to Jira. It is recommended that all changes to production servers are done during maintenance windows when the user access is limited.
8. Production: Deploy the snapshot.

    1. Use the Project Merge mode.
    2. Review the change and impact analysis in the Analyze step of the deployment.
    3. Now that the changes were staged at the staging instance, the change and impact analysis shown at this step should be identical with the one on staging. Those changes were tested and you can proceed with confidence.
    4. If the change and impact analysis is different than the one on staging, then both environments are different and this should be corrected.
    5. Proceed with the deployment (the change and impact analysis shows that everything is OK.)
    6. Review the Audit log for any warnings.
    7. Declare SUCCESS/FAILURE – based on the deployment result. If it is successful and the user access was limited, open the system for all users.

    8. Only in case of failure – restore at the production server the system snapshot created at step 6 above. Restart the process from the beginning. If the staging server is identical to the production, failures at this point aren't possible.

       
      Note – do not make changes directly to the production server

Automation

Automation of the above steps can be accomplished by using the public REST API.



💡 Let us know what you think

Feedback

Last modified on Jun 16, 2020

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.