Now SDK and Fluent: CI/CD Pipelines, Advanced ATF Testing, and Full Dashboard Support

Travis Toulson

Developer Passport Brazil Release Preview | Now SDK and Fluent

Featuring John Lind, Product Manager for Now SDK and Fluent

The Now SDK has shipped on a two-week cadence for some time now, which means the feature set has moved well past what most developers last evaluated. In the Now SDK and Fluent session of the Developer Passport Brazil Release Preview, John Lind, product manager for Now SDK and Fluent, walked through what has landed recently and what is arriving over the next several weeks.

The headline is CI/CD. The Now SDK command line now supports continuous integration and continuous deployment, and the recommended path for wiring it up is GitHub Actions. That closes the last significant gap in the SDK development model: developers have had source code, local development, and IDE-based authoring for a while, but the handoff from "my code is done" to "this version is running in production" still required leaving the toolchain.

CI/CD Support in the Now SDK Command Line

The new capabilities sit alongside the commands you already use. Just as there is now-sdk install and now-sdk transform, there are now CI/CD commands in the CLI.

These commands are built on the existing ServiceNow CI/CD REST APIs, which have been available for years. If you have built instance automation before, the underlying mechanics will look familiar. What is new is that the functionality is now first-class in the command line, which is what makes it practical to drop into a pipeline definition.

The pipeline itself is configured in YAML as a standard GitHub Actions workflow. Nothing about that is ServiceNow-specific, which is the point: the SDK participates in an ordinary CI/CD pipeline rather than requiring a parallel one.

The Demonstrated Pipeline

Lind demonstrated the model against the all-time great Hello World app to keep the focus on the pipeline rather than the payload.

The flow runs as follows:

Push development code from the local project to the repository.
Open a pull request.
On merge, the application is installed automatically onto the test instance.
The ATF regression suite executes against that test instance, with a link back to the results from the pipeline run.
On a passing run, a deployment request task is created for approval.
The approver checks the box, adds a note, and approves. The deployment to production can be initiated from within GitHub.

In the demonstration, one test was failing by design, a business rule requiring that referenced tasks be active had not yet been implemented. After the business rule was written and deployed through the normal SDK workflow, the pipeline re-ran the deployment, passed the suite, published a new application version, and produced the approval task. The full cycle completed in a couple of minutes.

The demonstration pipeline was itself generated from a roughly four-line description of the process handed to a coding agent, and it worked on the first attempt. Authentication was the one part that needed manual attention.

Prerequisites and Current Constraints

The application repository is required. The CI/CD capabilities are built on the app repo, which has been the primary installation path for the SDK. Lind was direct that the app repo has tradeoffs, but positioned it as a strong fit for the scenarios this pipeline targets: custom applications with small, well-defined scopes, and personalizations layered onto existing applications.

Authentication. The published sample currently uses Basic authentication. This is not the recommended configuration, and Lind was explicit about discouraging it. An SDK fix released the Friday before the session enables OAuth, and an updated sample using OAuth is expected within days of the broadcast. Teams in environments where Basic auth is disallowed, which is most regulated environments, should wait for the OAuth sample or adapt the pattern themselves.

GitHub is not mandatory. If GitHub is not part of your delivery path, the same CLI commands can be invoked from any pipeline tool, or run manually. You can stamp a validated version from the command line and hand off to whatever install process your organization already uses.

The Prescribed Deployment Model

The CI/CD work reinforces rather than replaces ServiceNow's guidance on SDK deployments. The recommended model:

Use Git and the Now SDK for sub-production deployments. Developers stay in their IDE and in source control.
Promote through the environment chain (dev, test, prod) and stamp a version at the point where the build passes validation in test.
Publish that stamped version to the application repository, and control the production deployment from the repository.

Using the SDK to publish directly to every environment, including production, remains discouraged. The tempting shortcut is now unnecessary: the pipeline tooling provides a supported path to production that preserves the version-stamping discipline.

ATF Testing in the SDK

Test automation support in the SDK has expanded substantially as well. The current capability set covers the full loop from the command line: authoring tests, executing them against an instance, and debugging failures without leaving the SDK.

An AI-assisted debugging capability is targeted for the end of September into early October. It addresses a specific and expensive problem: when an ATF test fails, the failure may be a genuine defect in the application code, or it may be a misconfigured or brittle test. Determining which is which is tedious manual work. The new capability is intended to investigate the failure, identify the cause, and act on it.

For teams running regression suites in a pipeline, this directly targets the part of the process that consumes the most engineering time.

Dashboards

A significant dashboard feature is arriving shortly. Dashboard support in the SDK had documentation gaps that made the existing capability hard to use. The update addresses those gaps and delivers coverage for building a complete dashboard using all 29 out-of-the-box dashboard widgets.

Configuring AI Coding Agents to Work Efficiently with the SDK

A practical portion of the session covered something that affects anyone using the SDK with an AI coding agent: agent skills must be installed at the project scope, not the global scope.

This is not a cosmetic preference. Without the skills in scope, an agent will still complete the work, but it will do so by brute force by searching the web, reading through SDK source code, and iterating far longer than necessary. Lind described running through roughly $170 of Claude budget in about two hours on a larger project before diagnosing the cause. The work was getting done; it was simply grinding.

How to Tell Whether the Skills Are Loaded

The diagnostic signal is straightforward: watch for now-sdk explain in the agent's tool calls. If the agent is not calling it, the plugin has almost certainly been lost from context. A reminder in the prompt generally restores it.

Recommended Configuration

Install the skills into your project directory on disk, not globally. In Claude Code, project scope shares the configuration with everyone working in the repository; local scope keeps it to you. Either works, but the files need to live in the project so they are not missed.
Declare enabled plugins explicitly in settings.json. Agents will often pick this up on their own, but declaring it is more reliable.
Use the npx @Servicenow/sdk invocation syntax. npx runs whatever version is installed in the current project, which lets you upgrade a single project without keeping a global npm install in sync across everything you work on. Staying on the latest SDK version matters given the release cadence.

The plugin and configuration repository is published on ServiceNow's GitHub organization, and the naming is close enough to the SDK repository itself to cause confusion. Be sure to check the link in the session materials rather than guessing. Complementary getting-started guidance for Claude Code, authored by Earl, is linked from the same materials. The SDK skills are not Claude-specific. The same configuration approach has been used successfully with Codex.

Where This Leaves the SDK

The community signal driving this work has been consistent: customers want a full source-code development model and a conventional developer experience on ServiceNow. Fluent and the SDK delivered the source code. CI/CD is the layer that makes it a delivery pipeline rather than a local authoring experience.

Lind's assessment of the current state: in the early days only a narrow set of metadata types and plugins were supported, and there was a visible wall between local development and any real release process. That is no longer the case. There is very little you cannot do with the SDK today, and the capability set continues to expand with deployments landing every week or two.

The model going forward is a clean one. Keep developers in their IDE and in Git. Stamp a version when it passes validation. Let the pipeline take it from there.

This session covered forward-looking product plans. Development timelines and feature availability are subject to change. Do not make purchasing decisions based on the roadmap items described here.