ServiceNow DevOps: Guides and Services

DevOps culture and organisational transformation

DevOps represents a fundamental shift in how organisations develop, test and deploy software. Traditional siloed development and operations teams create handoff delays and conflict. DevOps breaks down silos, embedding operations expertise in development and giving developers visibility to production. This transformation accelerates delivery and improves quality.

ServiceNow DevOps, now sold as DevOps Change Velocity, connects pipeline tools to Change Management so that a change request is created from a pipeline job, assessed against a change approval policy and, where the policy allows, approved automatically, with the commits, builds and releases behind it recorded on the change. The same practices also apply to developing on the platform itself: customisations can be tested and deployed through automated pipelines rather than manual procedures. Customisations can be tested and deployed through automated pipelines rather than through manual, error-prone procedures. Update cycles can be shortened and quality improved. Automation reduces human error and creates consistency across deployments.

Continuous integration and deployment automation

Continuous Integration practices require developers to commit code frequently—multiple times daily—and validate each commit through automated testing. Early detection of integration issues prevents large-scale conflicts and rework. Integration testing runs on each commit to catch incompatibilities between changes.

Continuous Deployment automation reduces deployment friction. Instead of manual procedures prone to errors, automated deployment pipelines execute consistent steps every deployment. Automation improves speed and reduces human error. Deployment scripts are version-controlled so that deployment procedures are audited and reviewed like code.

Deployment frequency should increase as automation matures. Early-stage DevOps teams might deploy monthly. Mature teams deploy multiple times daily. Increased deployment frequency delivers value to users faster and allows rapid response to issues or market changes.

Automated testing and quality assurance

Automated testing is prerequisite for rapid deployment. Comprehensive test suites—unit tests, integration tests, functional tests—run automatically on each commit and deployment candidate. Failed tests block deployment, preventing defective code from reaching production. Test quality is critical; poor tests provide false confidence.

Test coverage metrics should be tracked. High coverage reduces risk of undetected defects. Test suites should be regularly reviewed and updated as application features evolve. Dead or outdated tests should be removed so that test execution remains fast.

Infrastructure as Code and configuration management

Infrastructure as Code treats infrastructure definitions—networks, servers, storage—as code committed to version control. This approach enables rapid, repeatable infrastructure provisioning and supports disaster recovery. Infrastructure changes are reviewed like code changes and deployed through pipelines.

Configuration management ensures that infrastructure is consistent and documented. Infrastructure changes should go through version control and review before deployment. Configuration drift—unmanaged changes to infrastructure—should be detected and corrected. Compliance with configuration baselines should be monitored continuously.

Monitoring and observability for production systems

Production monitoring detects issues before they impact users. Metrics monitoring tracks performance: response times, error rates, resource utilisation. Log aggregation allows investigation of issues. Distributed tracing shows request flows across services and identifies bottlenecks.

Alerting should be tuned to surface genuine issues without creating alert fatigue. Alert thresholds should be based on performance baselines and impact analysis. Alerts should route to appropriate on-call teams automatically so that response is rapid.

Metrics and measurement of DevOps maturity

Organisations implementing DevOps should track metrics that indicate progress. Deployment frequency shows how often code reaches production. Shorter cycles indicate better automation and process maturity. Lead time for changes shows how long from code commit to production deployment. Shorter lead times indicate faster delivery capability.

Mean time to recovery tracks how quickly teams respond to and resolve production issues. Organisations with strong observability, automated testing and incident response procedures recover faster. Change failure rate tracks what proportion of deployments introduce defects. Lower failure rates indicate higher quality gates and testing coverage.

These four metrics—deployment frequency, lead time, mean time to recovery, change failure rate—correlate with organisational performance and customer satisfaction. Improvements in these metrics drive business value.

Deliberately injecting faults into a running system while observing how it responds is known as chaos engineering. By deliberately introducing failures in production and observing system response, organisations learn how systems degrade. Chaos testing builds confidence in resilience and identifies unexpected failure modes before customers encounter them.

Finding the right starting point by the problem you are actually facing

The DevOps guides on this site cover different jobs, and most readers arrive with one of three problems: a pipeline that fails too often, a release process that the governance team will not sign off, or a plan to move from manual deployments to something automated without breaking production. Starting from the wrong guide wastes time, because the advice in one guide assumes a maturity that the reader may not have yet. Use the table below to find the page that addresses your situation first.

How the guides fit together as a sequence

Read the cluster in the order a delivery program actually moves. Start with the failure patterns, because they tell you which controls are doing real work. Then look at governance, since the controls you keep must be ones an approver can explain to an auditor. Automation comes next, because it should only be applied to steps whose rules are already settled. The standards guide describes what consistency looks like across teams, and the roadmap turns all of it into a sequence with checkpoints. Reversing that order, especially starting with the roadmap, tends to produce a plan that automates the wrong steps first.

1. Diagnose the failures you already have, and write down which ones are caused by missing tests, unclear approvals or unclear ownership.
2. Agree the governance gates that the organization can defend, including which changes can move without a human approver.
3. Automate the repetitive steps that have clear decision rules, leaving judgment calls with people.
4. Standardize the practices across teams so that a pipeline built for one application can be understood by the next team.
5. Sequence the remaining work into phases with exit criteria, and review the plan against the metrics you started measuring in step one.

What a DevOps lead should expect from the cluster

These guides describe patterns, not a product configuration. They will not tell you which tool your organization should use, and they will not decide the approval thresholds for your change board. What they do give you is a set of questions that, if answered honestly, reveal where your delivery process is weakest. A team that can answer them is often ready to automate. A team that cannot is often better served by fixing its ownership and testing first, whatever the tooling looks like.

Should a small team read all of these pages?

Read the diagnosis page and the one that matches your immediate problem. The others become useful once the first decisions are made, and reading them in advance tends to produce a plan built on problems you do not yet have.

Does DevOps replace change management?

No. It changes how change management is evidenced. Automated tests, deployment records and rollback logs can satisfy many of the questions a change board asks, but the decision about risk still belongs to people who understand the business impact.

How do I know the program is working?

Watch the trend in deployment frequency, lead time, recovery time and change failure rate over several releases, not a single one. A single good release can hide a deteriorating process, and a single bad one rarely tells you much on its own.

Who should own the pipeline definitions?

The delivery team that releases the software, with the platform team providing the shared components. Pipelines owned only by a central group tend to drift away from the applications they deploy.

Using the cluster alongside an existing release process

Most teams do not start from nothing. They already have a change board, a set of manual deployment steps and some test suites, and the real question is which parts of that process to keep, which to replace and which to wrap. The guides are written so that a reader can map current steps against the sequence above and mark each one as trusted, partly trusted or unknown. Steps marked trusted stay as they are until something gives a reason to change them. Steps marked unknown should be examined before any automation is built around them, because automating an unclear step tends to hide the unclarity rather than remove it.

It also helps to keep a short record of what the team decided after reading each guide and why. Those decisions are often the most useful thing a future program inherits, because they explain which apparent inefficiencies were protecting something. A release process that looks slow may be slow for a reason the next team needs to know about before it is removed.

For teams that want the automation side handled as a service, the DevOps and automation service page describes what those services cover.