This is a guest blog by Botron Software, a provider of Agile Application Lifecycle Management solutions that extend JIRA’s capabilities to empower individual users and teams. In this blog, we discover how Botron’s Configuration Manager for JIRA helps large organisations to automate JIRA configuration deployments, eliminating the bottleneck when JIRA project administration is managed by a single point of contact.
If you’re a JIRA administrator in a large enterprise, chances are you’ll understand the pain of being responsible for all the changes requested for your company JIRA.
And if you are one of thousands of end-users – effectively clients of the administrator – you’ll definitely understand the pain of the single-point-of-contact bottleneck.
Delegated JIRA Project Administration
Botron Software’s Configuration Manage for JIRA directly tackles both of these painpoints.
CMJ is used by large enterprises to eliminate the administrator bottleneck by implementing a properly-delegated administration process – without jeopardising the health of your JIRA servers. It allows:
- Project admins to develop changes to the JIRA configuration of the projects they own.
- End users to test and analyse changes to the JIRA production server for non-direct consequences.
- The JIRA administrator to be the single authority, with rights to modify the production JIRA server.
This means that CMJ facilitates independent JIRA experimentation across the various divisions of an enterprise. Each division can use JIRA with different requirements, with both JIRA administrator privileges and the ability to develop workflows and screens for their specific needs, working offline.
Most importantly, whatever one division does in JIRA will not affect the others’ setup. Once everything is bulletproof, the company-level JIRA administrator then approves and imports the configurations.
4 easy steps to delegate your JIRA project admin
Step 1: Sandbox
Non-admin users have a development, or sandbox, environment where they can experiment with project configurations. In this playground, project admins can implement and test project changes as requested by end-users, creating JIRA tickets to describe project requirements.
Step 2: UAT
Project admins use CMJ on the development server to create project snapshots with the changes they need to be deployed. A snapshot will be then attached to the JIRA ticket and deployed on the UAT server, where end-users can test the requested changes. This can be repeated until end-users are satisfied with the changes.
Step 3: Staging
The JIRA administrator uses the final snapshot produced in step 2 and stages it. With CMJ, the snapshot will be deployed to a staging server and analysed for any unwanted changes. Once the change and impact analysis is completed, the administrator can schedule the change for production deployment and plan for communication and downtime.
Step 4: Production
The JIRA administrator uses CMJ to deploy, test and stage the changes in production with complete confidence. Once this step is complete, the ticket is marked as resolved.
The benefits of delegated JIRA project administration
With CMJ, JIRA administrators can automate most processes, saving stacks of time otherwise spent on manual work, as well as eliminating potential for human error. The tool also provides in-depth change and impact analysis to help administrators understand the effects of changes and make the right decisions for both the production servers and the company.
Try Configuration Manager for JIRA today
