ServiceNow DevOps Best Practices

This guide sets out the delivery practices a team should follow when it builds and releases changes on the ServiceNow platform, from source control and automated tests to branching, secrets and dependency updates. It helps a platform lead choose which standard to adopt first and how to record exceptions.

Continuous Integration and Source Control Discipline

Best practice: all code changes go through version control (Git) and trigger automated testing on every commit. This catches integration issues early, before they reach shared branches. Developers commit frequently (daily or more) to small features, not large batches.

Reasoning: frequent commits reduce merge conflicts and integration issues. Automated testing catches regressions immediately, not after weeks of development. Early feedback loops drive rapid, high-quality development.

Infrastructure-as-Code and Configuration Management

Best practice: infrastructure (servers, networks, databases) is defined in code and version-controlled, not manually configured. Changes to infrastructure go through the same review and testing as application code.

Reasoning: infrastructure-as-code enables reproducible environments (development, staging, production are identical), automates infrastructure provisioning (spinning up new environments is fast and error-free), and creates an audit trail of infrastructure changes.

Automated Testing at Multiple Layers

Best practice: implement unit tests (testing individual functions), integration tests (testing components working together), and end-to-end tests (testing full workflows). Run these tests automatically on every code change.

Reasoning: automated testing catches defects early and cheaply. Manual testing is slower and misses cases. A comprehensive test suite enables confident deployments and reduces defect escape to production.

Deployment Pipelines and Staged Rollouts

Best practice: code flows through a pipeline: source control, build, test, staging, production. Each stage has automated checks (tests pass, security scan passes, code review approved) before advancing to the next stage.

Reasoning: staged rollouts reduce risk. If something breaks in staging, it does not reach production. Automated checks catch issues early. Code review enforces knowledge sharing and code quality standards.

Monitoring and Observability

Best practice: every application and service has monitoring: metrics (CPU, memory, response time), logs (application and system logs), and distributed tracing (tracking requests across services). Alerts trigger when metrics exceed thresholds or errors occur.

Reasoning: monitoring enables rapid detection and response to issues. Without monitoring, problems are discovered by users (worst case). With monitoring, on-call engineers can fix issues before customers notice.

Incident Response and Blameless Post-Mortems

Best practice: when incidents occur, the team responds fast (documented playbooks, on-call coverage) and conducts blameless post-mortems (investigating what went wrong, not who is to blame).

Reasoning: fast response minimises user impact. Blameless post-mortems encourage honesty and learning, rather than blame and hiding issues. Outcomes drive improvements to monitoring, alerting, and procedures.

Container and Orchestration Practices

Best practice: applications run in containers (Docker) and are orchestrated at scale (Kubernetes or similar). This enables consistent deployment, fast scaling, and efficient resource utilisation.

Reasoning: containers eliminate “works on my machine” problems. Orchestration automates scaling and failure recovery, reducing manual ops work.

Feedback Loops and Continuous Improvement

Best practice: development and operations teams share metrics and feedback. Developers see production metrics and know the impact of their code. Operations feed back to developers on what is breaking.

Reasoning: shared visibility drives collaboration. Developers write code knowing how it performs in production. Operations understands the full lifecycle and can prevent issues.

Security as Part of the Pipeline

Best practice: security checks are automated and integrated into the pipeline: static code analysis (finding vulnerabilities in code), dependency scanning (finding known vulnerabilities in libraries), and secrets scanning (finding hardcoded credentials).

Reasoning: shifting security left (checking early) catches issues before production. Automated checks scale; manual security reviews do not. This does not replace security reviews but augments them.

Team Culture and Shared Ownership

DevOps requires a culture shift: development and operations teams own code quality and operational reliability together. No throwing code over the wall, no operations teams blaming development for poorly designed systems. Shared ownership drives collaboration and better outcomes.

Implementing DevOps Incrementally

You do not need to implement all DevOps practices at once. Start with continuous integration: automate testing on every commit. Once CI is working, add continuous deployment pipelines. Then work on infrastructure-as-code and automated testing. This phased approach allows teams to learn and adapt gradually.

Measuring DevOps Success

Track key metrics: deployment frequency (how often do you deploy?), lead time (how long from code commit to production deployment?), mean time to recovery (how quickly do you recover from incidents?), and change failure rate (what fraction of deployments cause incidents?). These metrics show whether DevOps practices are improving outcomes.

Choosing a branching model the whole team can actually follow

Many DevOps standards say to commit small and often, but they leave open the question of how branches are named, merged and retired. That open question is where teams disagree, and the disagreement often surfaces during the first release that crosses two branches. A standard should name one branching model for each kind of work, state who may create long-lived branches and why, and say what happens to a branch once its change is released. Trunk-based development suits teams that can keep changes small and protect the main line with fast checks. Short-lived feature branches suit teams whose work needs review before it touches shared code. Long-lived release branches are sometimes unavoidable, but they should be exceptions with an expiry condition rather than the default.

Branching choice	Fits best when	Main risk to manage
Trunk-based with short-lived changes	Changes can be finished within a day or two	Unfinished features reach the main line without a switch to hide them
Short-lived feature branches	Review must complete before merge	Branches age and conflict with each other
Long-lived release branch	A customer or regulator needs a frozen version	Fixes must be copied back, and copies drift

Keeping secrets and environment settings out of the code

A standard that says secrets must not be committed is necessary but not enough. The more useful rule describes where each kind of value lives. Environment addresses, feature switches and capacity settings belong in environment-scoped configuration that is versioned and reviewed. Credentials belong in a secrets store that the pipeline reads at run time, with access granted to the job rather than to a person. Teams often discover that a credential was copied into a script for a convenient test and never removed, so the review step should look for values that match the shape of a secret, not only for the obvious ones.

Making dependency updates routine rather than emergency work

Libraries, plugins and integration connectors age, and the longer they stay on an old version the harder the eventual upgrade becomes. A good standard sets an expectation that dependencies are reviewed on a regular cycle, with a small, scheduled update rather than a large catch-up project once a year. The standard should say who receives the update notices, who decides whether an update is applied, and how a dependency that cannot be updated is recorded, with a reason and a review date.

Writing team standards so they can be changed without a fight

A standard that is written once and never revised becomes a source of quiet non-compliance. Record each significant standard as a short decision entry: the context, the decision, the alternatives considered and the conditions under which the decision should be reopened. This makes it possible to see why a rule exists, and it gives a reviewer a fair way to propose a change. Keep the register in the same repository as the pipeline definitions, so that a change to a standard and the change to the pipeline that enforces it can be reviewed together.

1. Name the branching model and the rule for retiring branches.
2. List every kind of value a pipeline uses and state where each one is stored.
3. Set the dependency review cycle and name the owner of update notices.
4. Define the exception route, including who can approve a deviation and how long it may last.
5. Record the standard as a decision entry and link it to the pipeline setting that enforces it.

Should every team use the same standard?

Use one common core and allow teams to add rules for their own context. A rigid standard that ignores the difference between a customer portal and an internal workflow can be bypassed quietly, and bypassed rules are worse than no rule because they hide the gap.

What should an exception record contain?

The reason the standard cannot be met, the risk accepted, the person who accepted it and the date it must be reviewed. An exception without an end point can become the standard by default.

How do we check that a standard is followed?

Sample a small number of recent pipelines and read their definitions against the standard. Automated checks catch the easy cases, but a human reading a sample finds the places where the standard was technically met and its purpose was defeated.

The update sets and release management guide explains the packaging side of the same decisions, and the platform governance charter guide covers who decides on standards like these. For the test layer that these standards depend on, see the automated test framework guide, and for the connection between source control and ServiceNow records, the Azure DevOps integration guide is the next read.

ServiceNow DevOps best practices, in the order that pays off on the platform

On ServiceNow, adopt DevOps practices in this order: separate development, test and production instances with one promotion path, keep each application in source control, automate tests for the few workflows that must never break, then track defects and review code. Each step makes the next one safe.

Most teams already run several instances, so make changes travel one way only. A fix made directly in production breaks the promise that the next release behaves like the last test, so record every direct production edit as a process defect.

Source control works best when the work is packaged as scoped applications rather than loose changes in the global scope. A scoped application has a boundary, a version and a list of what it contains, so it can be compared, reviewed and moved as one unit.

Start automated testing small. Pick the handful of workflows whose failure would stop the business, such as raising an incident, approving a standard change or submitting a catalog request, and cover them with Automated Test Framework suites that run after every promotion.

Defects found during implementation need one home: a single tracked queue that records the step that exposed each one, the severity the business assigns and the build that fixed it. A defect is closed only when the original test passes on the next instance in the path, not on the instance where the fix was written.

Code review can be partly automated. Instance Scan can flag risky script patterns and configuration choices, which clears routine comments, but it cannot judge design. Keep a person on any change that alters a record’s life cycle. The DevOps and release management guide and the change governance and release management page cover who may promote and approve.

What is the first DevOps practice to adopt on ServiceNow?

Separate instances with a single promotion path. Without it no test result can be trusted, because production and test differ in ways nobody recorded.

How should defects be managed during a ServiceNow implementation?

Keep them in one queue, rank them by business impact, link each to the test that found it, and close a defect only after that test passes on the next instance.

Can ServiceNow code review be automated?

Partly. Instance Scan flags known risky patterns, which removes routine comments from review. A person still has to judge the design, the data impact and whether the change fits the process it supports.

Who should own CI/CD governance on the platform?

A named platform owner should hold the rules for who may promote changes and approve exceptions, with the release or change manager as second signature. For upgrade timing, see performance tuning and upgrades.