This blog post discusses configuration management in Jira.
Jira, as a tool, was never fundamentally designed to support the seamless movement of configurations from one environment to another. This is a common misconception, but unfortunately, it's not truly the case in practice.
The Illusion of Simple Configuration Changes
Imagine maintaining a Jira instance for a company with ten projects, each with intricate workflows, schemes (permissions, notifications), and numerous custom fields. These configurations form the backbone of a production environment.
Now, consider modifying some of these configurations. While it might seem straightforward, it rarely is. Let's look at a few examples:
- Workflow Modifications: Adding a new status to a workflow is often simple. However, removing a status is complex. It necessitates a mapping process to handle existing issues, including historical data, tied to that status. This isn't technically difficult, but it's far from a straightforward deletion.
- Custom Field Options: When dealing with dropdown custom fields, especially those with different contexts across various projects, deleting an option is risky. It can inadvertently impact or even lead to data loss from projects using those contexts and existing issues. The safer approach is to disable options, but even contexts cannot be simply deleted without potential data loss.
- General Field Management: Even seemingly simple tasks like reordering a field, adding/removing a field from a project, or disabling an option are not always trivial. While Jira offers APIs for many of these actions, directly manipulating production configurations via API carries inherent risks if not meticulously planned and tested.
The Development-to-Production Dilemma
The ideal scenario for any software system involves making changes in a lower environment (like a sandbox or development instance) and then deploying them to production. For very simple Jira use cases, this might work. However, it's generally not recommended as a standard practice for complex configurations.
When considering creating a new project with all its configurations, a sandbox environment might be useful for initial setup and subsequent deployment. Tools like Configuration Manager for Jira or Project Configurator exist for Data Center and can assist. Yet, there's a critical caveat: not every single configuration is always perfectly captured in a snapshot, and there are significant limitations.
The Never-Ending Sync Challenge
The core problem lies in maintaining true synchronization between environments. If a development or sandbox environment is a "copy" of production, that copy immediately begins to drift out of sync. Production continues to receive new issues, configurations, and data.
Consider the "moment after" mirroring:
- The base URL of the development environment needs to be changed.
- Scripts, webhooks, and outgoing emails must be disabled to prevent unintended actions.
- Even with these precautions, ensuring that every minor configuration change made on staging is flawlessly deployed to production is extremely difficult, if not impossible, in a live project scenario.
Jira was simply never designed with this level of automated configuration deployment in mind. It's not an "API-first" tool in the sense that configuration code can be committed to a repository and branches seamlessly merged, as in typical software development. Many critical changes still require manual execution through the UI.
Lessons from Other Tools (and Experience)
Experience with other tools, like Drupal, reveals similar configuration deployment challenges. However, Drupal has evolved to offer robust ways to deploy configuration changes. Jira, natively, doesn't possess this capability in the same mature way. While Jira Cloud is making strides, and Data Center offers some add-ons, these often introduce more problems than they solve in complex, live environments.
Personally, as Jira consultants, we've found that attempting these kinds of direct configuration deployments between disparate environments has caused more issues than it has resolved. The preferred approach is often to test thoroughly in a development environment, then meticulously re-apply those changes manually on production.
If there's a different perspective, or if new information changes this view, please share! We are always open to learning.
And if you're struggling with your Jira deployments or unsure how to manage configurations effectively, please reach out to us. This is what we do every single day, and we can provide guidance and pointers to help navigate these complex waters.
Configuration management in Jira is never straightforward. It's not a simple "commit and merge" process. Jira largely remains a tool where many things must be done via the UI.
That's all for this blog post. We hope you found it insightful and perhaps learned something new today. Thank you very much!