Skip to main content

Enterprise Plugin

The Enterprise Plugin is Q247's server-side component, which analyzes data about the team's work and calculates metrics from it. It handles all integrations that provide data: code repositories, ticketing systems, documentation and AI tool telemetry. It is configured from the Manage Organization panel, but installation and system requirements concern this component, not the interface itself.

The content of the analyzed data never leaves the infrastructure the plugin runs in. Repositories are cloned locally, and only the analysis result reaches Q247. The full split is described in Enterprise Plugin Security.

Scope of analysis​

Code repositories​

Code repositories are the primary data source. The plugin fetches the commit history and pull requests and merge requests from the repository, and calculates Calories, Increments and Lines from them.

Six systems connect through an API, each with its own connector type: GitLab (from version 14), GitHub (including GitHub Enterprise), Azure DevOps, Bitbucket (Cloud as well as Data Center and Server), Gitea and Gerrit.

A seventh type, Generic GIT, covers any Git-compliant repository, added manually by URL. It requires a correctly constructed address, together with login data, if the repository requires it. Network access to such a repository must be public or open for the IP address the given plugin deployment runs from.

The form fields and token permissions for each type are described in Connectors.

Tickets and documentation​

Jira and Confluence work in both the cloud and Data Center variants. You choose the ingestion method in the connector form. With webhooks, the plugin receives events from them, so data appears without waiting for a scan cycle. With API polling, the plugin reads Jira or Confluence itself, every hour or once a day at night, and needs no inbound connection. → Ingestion method in Jira and in Confluence

Confluence API polling requires Enterprise Plugin version q247-enterprise-plugin-linux-v2.6.0 or later. Q247 installs and maintains the Cloud Plugin, and the Client looks after updating the Private Plugin (Two deployment models).

From Jira, tickets, comments and field changes are processed, and with the Tempo integration enabled, worklogs as well.

Azure Boards and Azure Wiki work with an on-premises Azure DevOps Server and are served by a single connection. The plugin polls the Azure DevOps REST API every night or every hour, reads work items and wiki pages from the selected Team Projects and analyzes them locally. This integration does not use webhooks, so it needs no inbound connection to the plugin.

AI tool telemetry​

The plugin collects data on AI tool usage and passes it to Q247 in aggregated form. It has a built-in OpenTelemetry collector, so the organization does not have to maintain its own monitoring platform; alternatively, the plugin fetches this data from Dynatrace. Configuration is described in AI Tool Logs.

Repository analysis modes​

  • Full history analysis of the repository, from the first commit.
  • Analysis of a given date range, when the full history is not needed.
  • Incremental scanning at an hourly or daily interval, set on the source. Each run goes back two weeks from the last scan, to catch commits delivered with a delay.

The order of steps from installation to the first data on the dashboard is described in Running code analysis.

System requirements​

  • Red Hat Enterprise Linux 9 or newer, Oracle Linux 9 or newer, CentOS Stream 9, or Ubuntu 20 or newer.
  • Git client installed.
  • 50 GB of free disk space (more with parallel scanning of many large repositories).
  • 16 GB RAM.
  • 4 cores @ 2.5 GHz.

Two deployment models​

The plugin can run in the Q247 cloud (Cloud Plugin) or in the Client's infrastructure (Private Plugin). There is no functional difference between them; only where the process runs and who maintains it changes.

Cloud PluginPrivate Plugin
Where it runsQ247 infrastructureClient server
Who installs and maintains itQ247the Client
What needs to be opened on the networkaccess from the Q247 address to the SCM system's APIoutbound traffic from the Client's server
When to choose itby default, when there is nothing against itwhen code cannot leave the Client's network

The full procedure for both variants, together with what to prepare in the environment, is described in Installation.

Scope of this documentation section​

Installation walks through choosing a deployment model, creating a deployment in the panel, downloading the files and starting the process, plus a list of things to prepare on the Client's infrastructure side.

See also​