Druva’s Jarvis: An intelligent bot empowering custom workflow management

Druva maintains several hundred source code repositories. These are hosted in an on-premises GitLab platform, which directly or indirectly contribute to our offered products and services. Each code repository has a varying code size, number of collaborators, and programming languages, and thereby disparate policies of managing each repository. The workflows pertaining to the code repository may differ, but at the core, the aim of each is to maintain a high quality, continuously-tested code base to foster rapid, healthy, and agile development. 

To simplify the management of these complex workflows, Druva developed Jarvis, a configuration-driven bot for the standardization and enforcement of custom policies through automated checks to the code repository. The bot is easy to integrate with existing projects, scalable to multiple repositories, provides granular level control on specifying the code reviewers, and policy modifications at run-time. 

Integrating Jarvis

Druva primarily employs following tools for the bot’s continuous integration:

• Gitlab for source code management. 
• Jenkins as an automation server which executes various sanity, unit test (UT), and component test (CT) jobs.

Jarvis interacts with Gitlab and Jenkins, and therefore, it is important to understand the following features and terminology from Gitlab and Jenkins:

Protected branches in Gitlab 

Druva uses the default setting of protected branches in Gitlab. A protected branch is like any other branch and enables the following:

• Prevents its creation, if not already created.
• Prevents pushes from all but authorized users.
• Prevents anyone from force pushing to the branch.
• Prevents anyone from deleting the branch.

User permissions in Gitlab

Druva utilizes the following user permissions from Gitlab:

• Developer: This role is assigned to any project collaborator, and empowers them to create non-protected branches and raise merge requests (MR) to a protected branch, among many other accesses.
• Maintainer: This role is the highest project-level role and is only assigned to the Jarvis bot for facilitating the merge to a protected project branch.  

Merge requests in Gitlab 

A merge request (MR) is a request to merge one branch into another branch of Gitlab project. 

Comment in Gitlab 

A comment is a user text used to annotate the MR in Gitlab. Jarvis utilizes this feature as a medium for expressing and interacting with MR users.

Reviewers 

Reviewers are a set of users specified in the Jarvis configuration authorized to review the code. Jarvis provides the flexibility to hierarchically define the reviewers that fall under following categories:

• Directory/file reviewers: approve code in directories/file under their ownership. 
• Default reviewers: approve code in directories/files not defined in the Jarvis configuration.
• Release gatekeepers: approve MRs for release branches. 

Pre-merge/Jenkins job 

Pre-merge/Jenkins job is a script that is executed on remote machines and used for a variety of purposes including sanity checks, UTs, CTs, etc., by Jarvis.

The Jarvis architecture

The Jarvis bot is a vigilant monitor that orchestrates the communication between Gitlab and Jenkins, continuously probing based on the defined policy, raising concerns for any policy violation on MR, and eventually merging the code to a protected branch if all conditions are met.

As illustrated in the figure above, Jarvis is architected in a service-oriented fashion. Integral to its architecture are the following three  services:

Gitlab listener

This service is responsible for detecting any Jarvis instruction made in comments on theGitlab MR. Any detected instruction is then transformed into action, which is passed on to the Eyeserver.

As shown in the diagram above, the two instructions are on-demand execution of the pre-merge jobs and the approval from authorized reviewers after the code review.

Jenkins listener

This service is responsible for listening to the notifications from the Jenkins job about the status of Jenkins jobs scheduled by Eyeserver.

Eyeserver

This service is the heart of Jarvis, which performs its core operations. This involves triggering the pre-merge jobs on Jenkins, checking for policy, communicating violations, and ultimately merging the MR.

Its service-oriented architecture (SOA) allows Jarvis to scale and monitor multiple Gitlab repositories, where jobs can span across multiple Jenkins servers. Also, as no database is maintained inside Jarvis, the bot is quick and easy to integrate with multiple projects.

Users develop a piece of code in a non-protected branch and raise a MR to a protected branch. 

Jarvis evaluates the MR based on the project-specific configuration and modified files. It then generates and displays the requirement for a merge to succeed, which includes the following based on policy:

• Pre-merge jobs required to succeed.
• Code reviewers for approving the MR.
• Link to the Jira ticket in the MR title, etc.

This alerts the user of checks performed by the bot and the fixes needed for the code merge. The user also receives regular feedback in terms of job failure or policy violation in the corresponding comment regarding the status of the MR.

Key takeaways

Jarvis is a highly-configurable bot that makes the incorporation of custom workflows and policy in GitLab projects quite easy. Jarvis provides the unique facility of having granular control over the directories and files for review. With Jarvis’ configuration, a team can define policies and hierarchical code reviewers to lead the way in the development of their project.

Jarvis had been in production for more than three years, and has monitored more than 20,000 MRs. The bot has evolved over time by adapting to the custom workflow requirements of many different teams in Druva. Jarvis has been instrumental to incrementally making quality improvements, standardizing the development lifecycle, and effectively managing Druva’s codebases.

Explore the many ways Druva’s innovative solutions enable a range of next-generation cloud-based applications, including multi- and two-factor authentication for enhanced enterprise access security, in the Tech/Engineering section of the blog archive.