The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Thanks for visiting this category page on Runbooks in GitLab. This page belongs to the Respond group of the Monitor stage, and is maintained by Alana Bellucci who can be contacted directly via email. This vision is a work in progress and everyone can contribute. Sharing your feedback directly on issues and epics at GitLab.com is the best way to contribute to our vision. If you’re a GitLab user and have direct knowledge of your need for runbooks, we’d especially love to hear from you.
Runbooks are a collection of documented procedures that explain how to carry out a particular process, be it starting, stopping, debugging, or troubleshooting a particular system.
Historically, runbooks took the form of a decision tree or a detailed step-by-step guide depending on the condition or system.
Modern implementations have introduced the concept of “executable runbooks”, where, along with a well-defined process, operators can execute pre-written code blocks or database queries against a given environment.
We aim to extend Release Management and Incident Management further by rendering runbooks inside GitLab as interactive documents for operators. This will link from either a release or an incident management screen so when an action happens, GitLab points you to the relevant runbook. Additionally, we want to allow runbooks to trigger ChatOps functions as defined in gitlab-ci.yml.
Our vision for GitLab Runbooks is to help DevOps team reduce their Mean Time to Resolution (MTTR) by facilitating a central place for documented and automated procedures that explain how to carry out a particular process and connect responders to available automations to resolve incidents.
We are taking the first steps of Runbooks within the Release stage under the Release Management Group. We recently added the ability to create visibility to our user's runbooks by enabling an asset link to a runbook via gitlab#9427. In the next iteration, we plan to render a release progress view calculated from the linked runbook in gitlab#207258.
We are also furthering GitLab's Runbooks capability by linking runbooks to Alerts and Incidents as outlined in gitlab&1436.
While there are some offerings in the marketplace, they rely on heavy customization for every use case and are somewhat specialized (i.e. networking). Mature organizations have stitched together their own Runbooks, such as using Jupyter Notebooks for writing Runbooks.
Some of the main competitors for release management include deployment plans within XebiaLabs, release orchestration plans in Electric Cloud's Flow, and even layers of spreadsheets that are used to track tasks manually. On the Indicident Management side, we see the top providers for runbooks or playbooks are PagerDuty, VictorOps, and Opsgenie. The largest competitor of interest in this space would be the Opsgenie offering, as it is an Atlassian product, it can leverage a resemblance to a DevOps Platform suite.
PagerDuty has responded to the market need for runbook automation via the acquisition of Rundeck. As noted in a 451 Research article on the acquisition, this is a strategic move to meet the demands of the enterprise for more automation in incident response. GitLab has plans to investigate using Rundeck for Runbooks via gitlab#36655, this will be interesting opportunity to connect the PagerDuty lifecycle into GitLab Runbooks and Monitoring capabilities.
Runbook Automation (RBA) is a common terminology used in conjunction with the evaluation of monitoring and incident management solutions. Oftentimes, these are not evaluated exclusively by analysts as core offerings.
We have received several interested customer accounts and prospects in being able connect their own runbooks to release artifacts as described in gitlab#9427.
Group-level filtering for JupyterHub deployment
Many GitLab teammates have cited an interest in enabling the execution of Markdown as code, which can be seen in gitlab#198287, given that many steps or current runbooks may be stored as Markdown files in the current state. Another popular request is to make it easier to use runbook style operational code snippets via gitlab#36386. Both of these issues improve the operational effectiveness surrounding native GitLab runbook capabilties.
The Infrastructure team has conducted an analysis of the Jupyter Notebook Managed App via gitlab#255321. We are considering deprecating the capability via gitlab&4280, which is further supported by this walkthrough. Some of the key takeaways include:
A keystone of runbooks and making them highly usable can center around building out more comprehensive Runbook Automation to support all parties that use runbooks whether for Release Management, Incident Response, configuration of infrastructure, or even Alerting. In the Release Management space, we are working on building our more native GitLab runbooks as seen in gitlab&2665. Jupyter Hub offers compelling functionality in their notebooks, so we are also interested in expanding the Jupyter Notebook support for releases via gitlab&2663. One way to support the execution of these scripts could be to leverage and partner with a provider like Rundeck, which is being considered in gitlab#36655.
We have begun validating another GitLab Runbook experience described in gitlab&4218, which will use the issue foundation as a method for tracking tasks related to deployments or other events.