Transparent and confident software delivery with Dynatrace Release Analysis

“To release or not to release?” This is the question that drives many of us who work along the software-product lifecycle. Answering this question requires careful management of release risk and analysis of lots of data related to each release version of your software.

The tasks of identifying and gathering all necessary data while keeping track of the quality of new releases throughout all stages of your delivery pipelines are now more challenging than ever.

As your organization aims for faster delivery of value to your customers, the frequency of releases inevitably increases as more and more components and versions are deployed, sometimes in parallel. Organizations that have transitioned to agile software development strategies (including the adoption of a DevOps culture and continuous delivery automation) enforce automated solutions for such decision making—or at the very least, use automation in the gathering of a release-quality metrics.

The effort of manually collecting release-relevant data for decision making can easily become a bottleneck in your release automation pipeline and automated software lifecycle. There’s simply not enough time to manually gather all the facts you need to answer questions like:

• Is the new version safe to release?
• What risks does this release present compared to existing versions that are already in production?

Furthermore, the same information (for example, which version is deployed to which environment) is also valuable in other scenarios:

• When new features are expected to roll out in specific environments, stakeholders need to be on the same page regarding progress of the deployment.
• While analyzing customer problems, a developer might ask for version information related to deployed services to determine if the problems can be correlated with specific versions.
• When security vulnerabilities of certain libraries are reported, development teams need to track down all deployments of the versions that are correlated with issues so that proper update plans can be put into place.

Answers provided by built-in Dynatrace Release Analysis

Dynatrace provides answers to the following fundamental questions related to release insights and risk.

• Which versions are deployed across our deployment stages and production environments?
• Which release stages are these deployed versions in?

The filterable Release inventory page shows all detected releases. Each entry represents a process group instance. The list can be sorted based on version, deployment stage, or product. The Instances column shows the number of deployments of each release.

• What is the state of the change log for the new version?
• What known bugs have we identified and are any of them release blockers?

With the integration of issue tracking systems and configurable dynamic queries, Dynatrace shows you issue statistics and links to issues, alongside the related releases. Dynatrace currently supports integration with Jira (on-premise and cloud), GitHub, GitLab, and ServiceNow.

• Which version is currently handling a certain load (for example, if you are temporarily redirecting load with a canary deployment)?
• How is the new version behaving in comparison to previous versions?

To facilitate further analysis, the Release details page for each release displays basic metrics about the host where each release is deployed and enables easy navigation to the process groups or specific processes that run on those hosts.

How Release Analysis works

Dynatrace uses built-in version detection strategies. The latest detected version can be influenced by environment variables, K8s labels, and release events. Metadata is mapped according to technology standards and detection strategies.

Kubernetes metadata

For Kubernetes (K8s) you can use recommended labels for deployed pods to provide metadata for the related versions (label: app.kubernetes.io/version) and, optionally, a related product (label: app.kubernetes.io/part-of). A Dynatrace OneAgent with viewer permissions on the namespace can automatically detect such labels attached to your K8s pods. Thus, Version and Product metadata can be displayed in your release inventory. Kubernetes namespaces and configured Dynatrace host-group names show up as Stages.

If you don’t want to change your deployment configuration, K8s label updates also work. Dynatrace will update the captured versions after a few seconds.

kubectl label --overwrite pod yourPodId -n yourNamespace app.kubernetes.io/version=42

Other technologies

For any other technology, you can provide metadata via environment variables.

• DT_RELEASE_VERSION for Version
• DT_RELEASE_STAGE for Stage
• DT_RELEASE_PRODUCT for Product

For example, to detect the version of a process running on Linux, execute the following before launching the process:

export DT_RELEASE_VERSION=42

Events ingestion

If it’s cumbersome to add environment variables for processes in your environments, or you want to update version information without environment variable changes for your deployed software, you can send custom deployment events to Dynatrace APIs that explicitly provide version information.

Here’s example JSON that shows how to send custom deployment events to the API. Note that the processes are matched via specific tags:

{ "eventType": "CUSTOM_DEPLOYMENT",
  "attachRules":
   { "tagRule": { "meTypes":"PROCESS_GROUP_INSTANCE", "tags":"YOUR_TAG" }},
   "deploymentName":"${CD_JOB_NAME}",
   "deploymentVersion":"1.1",
   "deploymentProject":"YOUR_PRJ",
   "remediationAction":"http://revertMe",
   "ciBackLink":"${BUILD_URL}",
   "source":"YOUR_CD_TOOL",
   "customProperties":{ "Commits": "${GIT_COMMITS}" }
}

Release information from issue tracking systems

Dynatrace shows issue statistics related to monitored entities in the Releases inventory on the Releases page. For example, if the inventory shows an entry for a product Sock-Shop with version 1.7.3, the issue-tracking system integration will provide the count of bugs for Sock-Shop version 1.7.3.

You can integrate your issue tracking system with Dynatrace and specify queries with placeholders that are resolved at runtime.

Here’s an example Jira query:

issueType = Bug and component in ({PRODUCT}) and affectedVersion in ({VERSION})

What’s next

• Security issues related to releases will be highlighted the same way that other problems detected by Davis AI are already highlighted for your releases. This enables higher visibility of security risks that are introduced with specific releases.
• Technology versions, which are already captured for processes (for example, JVM versions), will be searchable and available for all releases. In this way, any license-related search tasks as well as technology upgrades can be automated.
• Services and metrics that show version information will be added. Davis AI already considers all deployment events as potential root causes of problems. To provide more analysis capabilities (for example, to compare releases and make version information more visible), we’ll also display version information on service overview pages and enable splitting and filtering for versions during the analysis or charting of metrics.

Further down the road, Dynatrace release analysis will also include SLO evaluation results, topology data from Smartscape, dependency graphs derived from Purepath data, and user behavior knowledge from Real User Monitoring to provide clear advice related to the question, “To release or not release?”

Get started

If you haven’t signed up already, check out the Dynatrace free trial and have Dynatrace OneAgent detect the metadata related to your releases.

• Introduction, Demo, Training: Performance Clinic
• Release observability is part of Cloud Automation, see the overview here: Dynatrace Cloud Automation Module provides observability-driven automation across the full lifecycle | Dynatrace blog
• Release monitoring | Dynatrace Help