Atlassian consulting for a UK software development provider

Solution

We split the project into three stages:

1. Review of the current workflows
2. Workflow fine-tuning in line with the Atlassian guidelines
3. Employee training

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:

• Gathered requirements on the customer’s premises.
• Set up the standalone versions of Jira, Confluence, and Service Desk in the customer’s AWS environment to enable workflow automation, custom reporting, and SSO authentication, along with minimizing the system downtimes.
• Reviewed the existing Jira solution to identify and remove unused components.
• Migrated the existing projects and issues, as well as the Confluence spaces from Atlassian Cloud to standalone instances.
• Implemented a Jira and Confluence failover solution.
• Organized on-site Atlassian training for the customer’s employees.

Audit

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:

• Some workflows were misconfigured and overcomplicated. For example, there were over 50 workflow statuses to choose from.
• Jira was underused because the employees didn’t fully understand the technology. As a result, they were familiar only with basic features, such as search, dashboards, time tracking, etc.
• The backlog was bloated with too many unresolved requests (some of them created 3 years ago). Some forms were overloaded with unnecessary fields, which also did not have proper descriptions.
• A whole range of automatic notifications were useless and required optimization.
• Some processes weren’t automated (e.g., postponing or reopening tickets).
• There were no Single Sign-On (SSO), no integration with Active Directory, and no CI/CD integration in place.
• Employees didn’t know how to work with Jira reports and portfolio.

Migration and process optimization

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.

Training

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:

• Jira/Confluence users. We demonstrated essential Jira and Confluence features useful for any Jira or Confluence user.
• Jira managers. During an Agile-oriented training, we described how to work with Scrum/Kanban projects and shared some useful tips for managers on simplifying the development process and collecting metrics on the project quality and results.
• Jira/Service Desk admins. We showed how to set up Jira and Service Desk and provided recommendations on how to fine-tune the deployed solutions.

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.

Integration

To improve user experience and speed up daily workflows, Itransition’s team integrated the Atlassian solutions with several third-party applications:

• TestRail, a test case and test management tool that helps teams manage and track their software testing efforts.
• Slack, a collaboration app that allows teams to create, update, assign, and comment on Jira issues, as well as receive Jira notifications in configured channels uniting all team members.
• Zabbix and Splunk to track and analyze events within the Atlassian stack.
• Twilio to use phone calls or SMS to notify the company’s Service Desk team, Service Desk manager, or CEO (depending on the risk level) when a specific service request needs attention.

Failover solution implementation

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:

• A fault-tolerant EFS file system
• A fault-tolerant Amazon RDS database
• A duplicate server in a ‘stopped’ state

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.

How it works

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:

1. Unavailable RDS or EFS data centers

   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.

2. Unavailable application server data center

   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.

3. Regional failure

   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.