Frequently Asked Questions - Digital Product Release
General
What is release management?
Release Management is the process of managing, planning, scheduling and controlling a software build through different stages and environments; it coordinates the activities (verifications, tasks, approvals, etc.) and flow of value within the release pipeline from scheduled story through deployment.
How has release management evolved?
Traditionally, release management has been a process driven by central IT and revolved around a “project” based way of working – where product/application features are bundled and released together as a part of a larger release package. This traditional method helps provide oversight into quality and compliance of changes moving to production, but at the same time also leads to inefficiencies (e.g. arduous governance, repetitive administrative work) that slows down the rate of releases, and as a result innovation, and does not scale well as products increase in both number and complexity.
As more organizations embrace agile and DevOps principles, this has also led to an evolution in release management. Modern release management operates under a “product” based way of working, where we see decentralized product teams autonomously planning, building, testing, and deploying their products on a more frequent basis. In this modern release paradigm central IT is less focused on directly managing all release activities/validations and instead looks to define proper controls and guardrails to support these distributed product teams in getting their work released in a compliant fashion.
What is Digital Product Release (DPR)?
Digital Product Release is a release process orchestrator, enabling product teams, either central or distributed, to plan and deliver new versions of software products consistently within the automated guardrails and visibility of central IT. DPR is designed to help organizations manage the process in which they ensure products/apps are ready to deploy, but does NOT encompass the capabilities to facilitate the actual development, testing, and deployment itself.
DPR is designed to help provide the benefits of governance while minimizing the headaches governance often brings. DPR provides an organization’s central release team visibility into what is being released while defining fit-for-purpose release templates and policies that drive necessary compliance across products with minimal overhead.
What pain points/problems could DPR solve?
To keep pace with the need for innovation, more organizations are embracing agile methodologies and shifting from a project-based to a federated, product-based way of planning, building, and delivering. While this shift has numerous benefits (increased release and innovation velocity, quicker feedback, etc.), it also comes with its own set of challenges:
- Central IT loses visibility into release as teams decentralize
- Central IT can become a barrier instead of an enabler to properly support, in a non-intrusive fashion, these product teams in releasing and realizing the benefits of frequent deployments
- As software products become more complex and numerous, release validation, particularly if it is manual, takes more and more time – leading to a need for automation
- Decentralized product teams are unsure of when they are ready to release without guidance from Central IT
- With no dedicated release management solution, many customers have augmented their change process to accommodate release, making change overloaded and arduous
How does DPR solve these pain points?
With DPR, we have built a dedicated release management solution that will enable customers to:
- Provide central IT with E2E visibility into release readiness across products being delivered via release dashboards and reporting
- Leverage release policies and fit-for-purpose release templates to automate validation of release readiness at each phase of a release
- Empower product teams to know when they are ready to release and how their work is measured
- Simplify cumbersome release and change processes, accelerating each
Why is ServiceNow uniquely positioned to solve these pain points?
ServiceNow is the market leading platform for the enterprise that allows customers to integrate with numerous data sources and build workflows and automation using said data to drive efficiency and optimization. With ServiceNow records and DevOps CI/CD data in ServiceNow, DPR will enable data-driven validation of release readiness – drastically reducing the manual release checks of the past and making it easier to scale software delivery.
What differentiates DPR from other release management solutions?
- E2E traceability across entire lifecycle within unified enterprise ServiceNow cloud platform
- E.g., during root cause analysis, with DPR can link release data (code changed, test results, security scans, epics/stories worked on, etc.) to corresponding change request and have traceability of what’s running in production to specific change deployment
- Seamless integrations across Incident, Problem, Change, and Release
- Ease of configuration to fit organizational governance needs
- Ability to build in automation (flow designer, business rules, etc.)
- Planned enhancements to enable better together use cases across ServiceNow portfolio
- E.g., deeper integration with Strategic Portfolio Management Workspace to tie together releases and progress toward OKRs or helping to ensure the features you are planning for are the right features to prioritize; policy linkage with IRM to manage enterprise compliance
Technical and usage questions
Who are the key personas that would use DPR?
What are the high-level capabilities delivered with DPR?
- Release templates: Fit-for-purpose, configurate release templates
- Data-driven validation with PaCE: Policies to automatically validate release compliance based on CI/CD and ServiceNow record data
- CI/CD tool integrations: Leveraging the DevOps data model (same as DevOps Change Velocity) to integrate with CI/CD tooling
- Approval definitions: User defined, manual approval tasks
- Product & version management: Request/manage products and release versions
- Change requests: Raise change requests with release traceability
- Release dashboards: Visibility into release health & execution status
- Guided setup: Guided release admin setup experience
What are the OOTB policies included in the DPR Policy Content Pack?
- all_completed_stories_have_associated_commits
- all_planned_stories_are_completed
- code_coverage_threshold
- integration_test_pass_threshold
- load_test_pass_threshold
- no_critical_vulnerabilities
- regression_test_pass_threshold
- smoke_test_pass_threshold
- system_test_pass_threshold
- user_acceptance_test_pass_threshold
Does DPR entail a complex implementation?
Most of the work in implementing DPR will be in the business process and functional documentation of your current and desired future-state release process. Technical implementation of DPR is straight forward and we’ve built a guided setup experience OOTB. Achieving first value typically will not require professional services, especially if you understand your release process.
What are the main actions required to install and configure Digital Product Release?
Digital Product Release must be downloaded and installed from the store. After installing the plugins, Digital Product Release has a guided admin setup experience to make it simpler to deploy and quicker for customers to get to value. This involves defining manual approval definitions, activating policies for automated validation checks, creating release templates, and (optionally) determining release readiness targets (go-no-go dates).
For customers that have a higher DevOps maturity and/or are operating in a more distributed fashion, DPR leverages the DevOps data model and DevOps Change Velocity tool integration experience to bring in CI/CD data for release planning and automated policy validation.
Delivery through the ServiceNow Store
To provide rapid updates, Digital Product Release is delivered to customers through the ServiceNow® Store. There is also a ‘true-up’ of a version of Digital Product Release in each Platform release which will show up in an equivalent way to other products. Due to necessary lead-times, the version included in the Platform/family release is behind the store.
The product has components in the store. The store application names are:
- Digital Product Release
- Digital Product Release Content Pack
In addition to rapid updates, store releases also mean that the DevOps product will support current or ‘n’ and the immediate prior or ‘n-1’ releases.
Will integrations require MID server? How about Integration Hub?
The MID Server will be required when the customer’s toolchain is not accessible directly by their ServiceNow instance.
Integration Hub will be leveraged by some of our integrations. Customers will be entitled to use the out of the box integrations (including Integration Hub) for DevOps purposes when they purchase ITSM Pro.
Which integrations will be available? What data elements will they pull in?
The list of integrations is documented in product release notes and the overview section on docs.servicenow.com. The product includes GitHub, Bit Bucket, Jira (for planning information), ServiceNow SPM (Agile 2.0), Jenkins (with additional data such as test and artifacts accessible through the pipeline), Azure DevOps Boards, Repos, and Build Pipelines, as well as GitLab for Code repository and CI/CD, and test and security scanning tools. New integrations will be added through the store releases. Note that some partners will also be providing their own integrations to our product data tables. Some integrations are available as Innovation Lab releases in the ServiceNow Store. Innovation Lab releases do not have ServiceNow Support coverage.
Data elements are documented in the Data Model in the product documentation.
What are ways I can adjust/configure governance within DPR?
- Create a variety of release templates, with differing manual tasks and automated policies, designed to best fit different types of product/software releases (e.g., major, minor, hotfix, patch, upgrade)
- Centrally defining release readiness targets (deployment dates) or allowing teams to deploy continuously once their releases are validated
- Modify OOTB catalog request flows to define the level of approvals necessary for creating new products, versions, and releases
Will my AppDev teams need to log into DPR to manage their releases?
DPR aims to keep development teams in the tools they work in as much as possible. Product Managers will log into DPR on a ~weekly cadence to check on release compliance. Only when something is non-compliant will a PM reach out to developers to collaboratively fix whatever is non-compliant about the product release. AppDev teams would log into DPR on an as needed basis, but not a frequent expectation.
Where does DevOps and DevOps Change Velocity fit?
DPR leverages the DevOps data model to integrate with 3rd party CI/CD tools and use that data to drive automation via policy checks. The CI/CD tool integration experience within DPR is lifted directly from DevOps Change Velocity and will mirror the evolution of that experience. Additionally, change creation for DPR can be automated with DevOps Change Velocity.
Does DPR require DevOps Change Velocity?
No. While DPR and DevOps Change Velocity both rely on the DevOps data model to intake and leverage CI/CD tool data, neither application is dependent on having the other implemented. In fact, we see DPR as the more likely starting point for most customers and will be the point of entry for customers to integrate with their DevOps tool chains for use in automated release policy checks. It is true that if a customer has adopted either DPR or DevOps Change Velocity, getting started with the other application is more straight forward.
How is release planning connected to DPR?
We do not anticipate customers to perform their release planning in DPR. Customers should expect to leverage our OOTB planning tool integrations to import in their top-level features/epics into DPR to track during release execution. Updates to feature/epic and underlying work item status in your planning tools will automatically translate to DPR.
Are there any limitations to the types of releases that DPR can manage?
Yes, DPR is built to support software product releases. Today, DPR does not support hardware releases or large projects (e.g., cloud migration).
How is DPR licensed?
Digital Product Release is entitled as a part of ITSM Pro and ITSM Enterprise.
Where the Digital Product Release uses Integration Hub for connections, the licensing for that usage of Integration Hub is included within the ITSM Pro licensing.
Other FAQs
ServiceNow has an existing Release Management application, Release Management v2 (RMv2). How is DPR different?
Release Management v2 is a light-weight application (just a set of tables) with no workflows built OOTB. Customers that have implemented RMv2 have needed to heavily customize the application to fit their requirements.
DPR is built with modern release management best practices in mind and ships OOTB with numerous capabilities (see above). DPR is built to be highly configurable so that customers can modify DPR to meet their requirements without bringing complexity in upgrading to the latest ServiceNow releases. Additionally, DPR will be a continued area of investment for ITSM and customers using DPR will see new features and enhancements with each release.
How is Change Management related to Release Management?
Change Management is the process of managing changes (planning, scheduling, assessing, implementing) to an organization’s IT infrastructure that may impact IT services or systems with the goal of ensuring that changes are made in a controlled manner and do not negatively impact IT services or systems. Release Management is the process of managing the release (planning, designing, building, testing/validating, deploying) of new or updated IT services or systems into production.
In simple terms, one can think of Change Management as the final gatekeeper with the objective of protecting the production environment and Release Management as the implementation process that prepares new code/changes ready for deployment to production. Before the product of a release - a new version of an IT service or application - can be pushed to production, a change request is necessary as the final gate to minimize potential negative impact and provide traceability.
What is the difference between a deployment and a release?
Often the terms deployment and release are used to refer to the same thing – pushing code to production and making it available to end users. In modern software delivery, these concepts are should be thought of separately, where a deployment is the act of pushing a software version to an environment and a release making the software available to a user (often using feature flags). Deployments can and often happen frequently, and for some organizations continuously, where releases are typically scheduled on a monthly, quarterly, or even longer cadence. In a release, several deployments of new software versions can be pushed to production, but those new features are made non-visible via the use of feature flags (think of this as an on/off switch for a feature). Once a release go-live date is reached, those feature flags are changed to “on”, and those new features are available to end users.
Learning & Resources
Where can I learn more about Digital Product Release?
