|Content Last Reviewed||
Thanks for visiting the direction page for DevOps Reports in GitLab. This page is being actively maintained by the Product Manager for the Analytics group. If you'd like to contribute or provide feedback on our category direction, you can:
GitLab has a extraordinary breadth for a single application, allowing users to implement the entire DevOps Lifecycle with ten stages of functionality ranging from portfolio planning and management; on the one hand, all the way to monitoring and service desk on the other. Each of these stages offers persona specific dashboards such our security dashboard, a dashboard for monitoring applications, for auditors and compliance officers, for engineers tracking the progress of code reviews or software development leaders who want to understand fluctuations in the productivity their software teams.
With this breadth, GitLab has the potential to provide a level of insight that few others can match. To help users more fully realize this potential we want to address one important view we currently lack: the ability to pull all of these disparate pieces together into a single comprehensive view that cuts across stage boundaries and allows users to re-mix the metrics available in GitLab into dashboards which meet their specific needs.
The DevOps Reports category aims to address this by providing users the ability to:
In addition, DevOps Reports, provides technical infrastructure, small primitives, for product teams across GitLab to:
DevOps Reports is comprised of the following capabilities:
During our first phase we will focus on creating simple mechanisms that will allow us to quickly build-out a robust Metric's Library. These include re-using and expanding the query capability of our existing Insights feature and a new Metrics APIs for pre-computed and aggregated measures. We will also build out basic capabilities in Report Pages to allow users to explore Metrics from the metrics library, export metrics data to CSV, and embed charts in third-party wikis and dashboards.
We will also begin enhancing current product capabilities such as the metrics displayed in Group Recent Activity to prove out the power of Report Pages to enhance existing product features by providing drill-down and additional insights.
Optimizing Flow — In conjunction with our emphasis on Value Stream Management, we will implement common DevOps and Value Stream metrics such as the DORA metrics and Flow Metrics in addition to general value stream process measures for evaluating the performance of a particular value stream process step or stage, detecting out-of-control queues, process bottlenecks, etc.
Planning & Tracking — We aim to assist agile project managers and agile teams with frequently used measures such as team velocity, cumulative flow and eventually predictive analytics to help with planning.
Develop & Test, Secure & Release — Development teams often wish to monitor status of builds, test code coverage, security scan results, defect counts and other measures which are also used by Release Managers to gauge release readiness.
Measures of Value — Our existing Prometheus integration provides a powerful capability for tracking the outcome of a continuous delivery release in terms of business metrics that matter. We hope to build on this with deeper integration to our system for feature flags and a/b testing.
DevOps Maturity — We will begin with relatively straightforward measurements of usage and adoption as an evolution of our DevOps Score capability. Eventually leaders will be able to set and specific KPIs and process targets derived from out-of-the box Metrics Library metrics on an executive dashboard.
This is an important area of investment for GitLab which provides immediate value to end-users while also establishing foundations to accelerate our work in Value Stream Management.
DevOps Reports will allow us to:
Specific near term steps in this area include:
This category is currently Minimal. The next step in our maturity plan is achieving a Viable state of maturity.
For DevOps Reports to be Viable, development teams must be able to construct dashboards from the most consulted / customer requested metrics and find these provide a level of situational awareness on a daily basis or weekly basis. We will verify this via dogfooding with at least ten development groups inside GitLab.
Furthermore, we expect the use of report pages to enhance existing capabilities with drill-down experiences to increase traffic to Analytics pages by 10% over the next 9 months and by 200% over the next 18 months.