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
Interested in joining the conversation for this category? Please join us in our public epic where we discuss this topic and can answer any questions you may have. Your contributions are more than welcome.
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.
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 mangement 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.
Runbook Automation (RBA) is a common terminology used in conjunction with the evaluation of monitoring and incident mangement 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.
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.
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.