Itransition reviewed and fine-tuned the customer’s software development and delivery workflows, optimized their Atlassian stack, and provided training sessions for employees.
Our customer is a group of companies that includes Degree 53, a software development provider, and Sharp Gaming, a gambling software development company. The customer is based in Manchester, UK, and provides a wide range of services covering UI/UX design, web and mobile app development, digital marketing services, and software consulting for the sport, online gambling, finance, education, and retail industries.
To manage their corporate software development processes, the customer implemented Atlassian Jira, Service Desk, and Confluence for 80+ employees. However, over time the implemented suite started failing to keep up with the corporate growth, and couldn’t support the daily tasks anymore. With 200+ custom fields in Jira forms and 50+ workflow statuses, it became hard to work with the existing Atlassian instances.
Typically, the Service Desk synchronized with Jira, with all requests from the Service Desk forwarded to Jira for the development team to process them. However, attachments and data in custom fields got lost regularly, so employees had to duplicate their requests manually.
Other issues included:
The customer understood these inefficiencies and wanted to simplify the Jira and Confluence administration. Considering our long-standing expertise in Atlassian consulting proven by our Atlassian Gold Solution Partner status, Itransition joined the project to audit and fine-tune the customer’s Atlassian-based workflows, as well as organize employee training.
We split the project into three stages:
Apart from demonstrating advanced Atlassian features and sharing tips on the platform’s usage, we also initiated the accumulation of corporate knowledge through Confluence Questions.
In the course of the project, Itransition’s team:
To formulate clear requirements, Itransition’s Atlassian experts held on-site interviews with the employees responsible for different operational areas (top managers, business analysts, developers, QA and DevOps engineers). The collected feedback helped us identify the following issues:
With the audit results in hand, Itransition’s team drew up a roadmap for improvements. Among them, migration was the key to optimizing Jira-based workflows.
We set up Amazon EC2 and Amazon RDS environments to install standalone Atlassian solutions and migrate them from the Atlassian Cloud to the Atlassian Server. Then, we migrated Jira and Confluence data (existing projects, spaces, and issues) to the standalone instances. We also integrated Jira with the customer’s Active Directory to facilitate user authentication.
The migration allowed the customer to have better control over the Atlassian deployment while being more flexible about customizations. After the migration, our team moved on to workflow optimization.
While the Atlassian guidelines recommend using workflows with five steps maximum, some of the customer’s workflows contained up to 20 steps, which were rather difficult for the teams to follow and manage because of their sheer quantity. Users could hardly grasp workflow statuses and follow task lifecycles overall.
To optimize the existing processes, Itransition’s team removed all the unused fields, statuses, project schemes and workflow steps. Thanks to the cleanup, we managed to reduce the number of steps in the customer’s workflows to six. We created a set of simplified workflow templates and migrated all complicated workflows to them.
Additionally, we fixed misconfigured project links which hindered the integration between the Atlassian applications.
Itransition’s team also automated the postponing and reopening of Jira issues and set up a unified Help Center for all Service Desk users.
Within Atlassian consulting, Itransition’s specialists introduced the ITIL framework, thus aligning IT processes with the customer’s business needs. We set up the Jira Service Desk in accordance with the framework and assisted employees in learning the ITIL principles.
Our Atlassian consulting services included user training, to help the customer’s employees use Jira, Service Desk, and Confluence more efficiently. We conducted on-site training that covered such aspects as project and product management (Scrum/Kanban), CI/CD, and release version management.
To personalize training sessions, our Atlassian experts divided users into several groups, preparing personalized training for each group:
Overall, we conducted 15 group training sessions, as well as several individual ones. We also held several specialized training sessions for QA engineers and admins.
Thanks to the training, employees learned how to get the most out of the Atlassian products and manage them properly. Developers could now use Jira as their essential tool for daily tracking of all development-related processes. Using Confluence as a knowledge base and a document repository, the employees also got the opportunity to document all processes and accumulate best practices.
To improve user experience and speed up daily workflows, Itransition’s team integrated the Atlassian solutions with several third-party applications:
Providing product development services, the customer wanted to ensure uninterrupted development with no downtimes. Therefore, to ensure the fault tolerance of the Atlassian stack in the AWS environment and to avoid downtimes, we implemented a failover solution. The system’s fault tolerance is achieved with the following three factors:
The solution architecture comprises the following components:
Load Balancer. A single access point to Jira and Confluence, as well as a single point of the HTTPS traffic encryption. It monitors EC2 servers and redirects traffic to an active instance.
Amazon EC2 provides scalable computing capacities in the AWS cloud. In EC2, two application servers (primary and secondary) are deployed in different datacenters of one region. The local EBS file is saved as an AMI image and could be deployed in any region, if necessary. EC2 stores only the stateless components of the system and applications, including all system files and configured applications except stateful data that changes over time (such as attachments, plugins, indexes, logs, and cached data).
Amazon RDS. A cloud database deployed in the same region as EC2 servers with the Multi-AZ (availability zones) option enabled. It means that the database is replicated across several data centers in this region, which increases its availability and fault tolerance. Our team configured regular, incremental and full database backups.
Amazon EFS. A file system, that is replicated across several data centers in a region, which increases its fault tolerance. It is mounted on each EC2 instance and stores Jira and Confluence stateful (changing) files. Access to the file system is guaranteed even if one or two data centers are unavailable.
CloudWatch monitors the status of the application servers and takes action if the main server becomes unavailable. It stops the main server to prevent the concurrent start of two application servers and then starts the secondary server while the Load Balancer automatically switches to a healthy instance.
The EC2 servers are connected to the same Multi-AZ RDS database. The primary instance is backed up by an identical secondary instance. All stateful files are copied between instances every 1-2 hours or on a daily basis. There is no need to copy stateless data as the same database is already in use. If the main instance is down, the apps are started on the secondary instance, which is usually takes about a minute to get loaded. The Amazon Route53 DNS web service switches the domain name to the secondary instance.
Itransition’s team considered several potential failover scenarios:
This scenario is covered by the fault-tolerant design of the services themselves, so no actions are required. The solution notifies the customer’s support engineers automatically.
When the primary application server becomes unavailable, the secondary application server gets activated automatically. It uses the same EFS/EBS file systems, while all data remains relevant. The support engineers immediately receive the respective notification.
When all regional servers are unavailable, recovery is performed through backup systems. Up-to-date backup versions of the database and the EFS file system are restored in another region. EC2 is restored from the saved AMI image in the same region. The system starts with minimal data loss due to regular database backups. The average recovery time in another region is around 3-8 hours.
Itransition reviewed and fine-tuned the customer’s existing workflows, optimized and migrated their Atlassian stack, as well as provided training sessions on the use of the updated software.
Since Itransition joined the project, the number of the active Atlassian users on the customer’s side has tripled. The system keeps its flawless performance, and users continue sharing their positive feedback about the solutions.
Through professional IT consulting on the Atlassian stack, Itransition’s team helped the customer reach these important goals:
Overall, we have found Itransition […] to be an engaged, hardworking team who have become a key part of our Sharp Gaming team. We look forward to continuing the working partnership with Itransition.
Richard Wagstaff
Operations Director, Sharp Gaming