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.
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 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 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.