Instead of creating a timechart, a table of successful and failed deployments can be quickly created from the same data using the stats and table commands.īut, there are even deeper levels of development and deployment data that can be harnessed to quickly ask and answer questions about concerns such as dependencies, and the entire software bill of materials. ![]() This sort of timechart also puts you well on your way to establishing productivity and developer metrics such as how often services are deploying and how often deployments succeed or fail. Visualizing the start, pending state, and completion of a repository’s deployment pipeline Knowing when deployment events happened allows you to more easily establish if a given deployment was involved in or precipitated an incident or outage.įigure 1-2. This can be accomplished with some very basic SPL to create a timechart. The easiest of these questions is determining when deployments started and finished. Leveraging Splunk Dashboards and SPL you can easily observe deployments, code scanning results, and other important data at a glance! But before building anything, think about those questions listed earlier and pursue some of the easy ones. Once your CI/CD data from Gitlab (or any other place) is in Splunk the world is your oyster. GitLab SBoM (CycloneDX), Dependency Scanning, and Static Code Analysis Scanning results from Gitlab CI deployment pipelines viewed in Splunk. Combined with the highly configurable and arbitrary needs of deployment pipelines, it means tools like curl can be used to send that data out to other systems like Splunk (Splunk Lantern guide).įigure 1-1. Luckily artifacts from deployment pipelines are usually written to disk for sharing between pipeline steps and historical auditing. ![]() These questions require contextual data about pipeline runs that may be difficult to acquire.
0 Comments
Leave a Reply. |