04/28/2021 | Press release | Distributed by Public on 04/28/2021 10:16
'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:
Furthermore, the same information (for example, which version is deployed to which environment) is also valuable in other scenarios:
Dynatrace provides answers to the following fundamental questions related to release insights and risk.
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.
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.
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.
Each Release details page shows a summary of captured release metadata and provides links to the process group and hosts where the release was deployed.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.
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.
Recommended Kubernetes labels mapped for release meta data.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
For any other technology, you can provide metadata via environment variables.
For example, to detect the version of a process running on Linux, execute the following before launching the process:
export DT_RELEASE_VERSION=42
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}' } }
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})
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?'
If you haven't signed up already, check out the Dynatrace free trial and have Dynatrace OneAgent detect the metadata related to your releases.