Botron Software

CMJ 101


Warning: mysql_real_escape_string() expects parameter 1 to be string, object given in /home/content/74/11756174/html/wp-includes/wp-db.php on line 1093

Test – Staging – Production

The procedure of staging any changes before they are made on the Production server is a recommend IT best practice. The following article describes how to such environments: Establishing Staging Server Environments for Jira.
This is the core use case for which Configuration Manager for was designed – automated promotion of Jira project configuration from Test through Staging to Production Jira environment.

Duration < 10 min             Environments 3 Jira Servers            Snapshots Project Snapshot             Deployment ModeProject Merge             Difficulty Easy             REST API Supported

3 Servers are required. Test, Staging, Production. The Staging should be identical or close replica of the Production.

 

 

Step by Step Diagram

 

 

Steps

This use case have 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 snapshot for project A
3. Staging: (optional) Create system snapshot for backup
4. Staging: Deploy snapshot

    1. Use Project Merge mode
    2. Review the change and impact analysis in the Analyze step of the deployment
      Now that Staging is 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 creation of 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 a failure. Restore at the Staging server the System snapshot created at step 3 above

Staging to Production

5. Staging: Create snapshot of project A
6. Production:(optional) Create 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 snapshot

    1. Use 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, 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 are 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 access to the users was limited, open the system for all users.
    8. Only in case of a failure – restore at the Production server the System snapshot created at step 6 above. Restart the process from the begining, 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 using the public REST API.