Developing and validating changes in staging
Change the configuration in staging
Now, it's time to change the required items on staging – custom fields, workflows, schemes, etc. in order to satisfy the requirements that have been identified.
Validate those changes internally, analyze impact on other projects
Review and validate the new configuration. Depending on the complexity and scope of proposed changes, it may be important to check if:
- The workflows are complete, with all required states and transitions.
- Issues have fields to hold all required information.
- Every issue has all its required fields filled, either at creation or at some point in its workflow.
- Everybody is granted permissions in line with tasks and responsibilities, but not more.
- All screens are verified, as they will be seen by end users.
- All main use cases are verified – create, transition, and edit typical issues, use filters, dashboards, or reports to obtain the required information.
It is especially important that attention is paid to the impact of these changes on other projects. This impact is produced when you modify a configuration object (e.g. a workflow scheme) that is shared with several projects. Most often, JIRA will show you where a configuration object is used. Following the example, the next image displays the workflow schemes administration page, where you can see which projects use every active workflow scheme:
If you detect that a configuration object is being changed and it is used by other projects, you should analyze the impact of the changes on those other projects, eventually performing some of the reviews and tests mentioned above. The most complex situation would be that you detect that the proposed changes are incompatible with other projects when the impact on them is not acceptable. In this case, your best option is to copy the configuration object that is to be modified, so that one of the copies can be changed, while the other (used by other projects) remains untouched.
Note: Changes to custom fields with impacts on other projects can be ignored if the Smart custom field contexts option is enabled during the promotion of changes to production.
Validate changes with users
When all changes are implemented in staging they can be shown to the users and reviewed jointly with them. The goal is getting the users to view and approve the new configuration, or gather feedback about desired changes.
Note that in some cases this user acceptance will be mandatory, according to the organization procedures.
Knowing what has changed
Perhaps at some point during the development, you may be asking yourself what has changed in the configuration since you started from the production clone. There are two ways to get a practical answer to this question:
- Export the configuration from the staging instance, and run a simulated import into production. This will print all differences between the configuration for the exported projects in staging and their current configuration in production.
- Before starting developments in staging, export the existing configuration for the projects and save the resulting XML configuration file. When you want to check what has changed as a result of the new developments, export the new configuration into another XML file and compare it to the one you obtained before the development started. Any diff tool for text files available in your environment can be used for the comparison and the output XML file is designed so that it can be used to track configuration changes. This method has the advantage that you can store XML files of different stages of the development and then use them as a "version control" of the whole stream of configuration changes that are being made in the project. You could compare and view configuration changes in different moments in time and even restore the configuration in the staging instance to one of those past configurations (importing the configuration of that XML file into staging.)
💡 Let us know what you think