Skip to content

Validating Seeq Integrations Against Seeq Continuous Delivery

Seeq ships continuously. The connectors that come with Seeq ride that cadence safely because they are built and tested inside Seeq's own pipeline: every Seeq release is validated against them before it reaches you.

An integration built by anyone else does not get that. Seeq's Connector SDK provides building blocks — a standard conformance test suite, and version metadata the Seeq agent checks when it loads a connector — but how a third-party integration is validated against each new Seeq release is left to whoever built it. For most integrations, the honest answer is that it is not, until something stops working.

Our position is that an integration from Endeavor Engineering should carry the same validation expectation you have of a feature built into Seeq. This page explains how we meet that from outside Seeq's pipeline, and then shows the specifics for our Seeq connectors.

Why outside the box is harder

Inside Seeq, a change to the platform and the tests of everything that depends on it run together. Outside, none of that is given:

  • We learn about a release when it is published, not while it is being made.
  • Nothing tells us a release matters to us. A Seeq SDK release can change hundreds of classes; the question is whether it changes the handful our connector actually uses.
  • Some breaks are invisible to inspection. A method that gains a new checked exception, or a test library that moves version underneath us, reads as "compatible" in any API comparison and still stops the build.
  • Your Seeq agents are not ours. A connector can declare the oldest agent it supports, and the agent enforces it strictly — but whether that declaration is right for the agents actually deployed is something only the integrator can know.

So the work is not one test. It is a loop: notice every release, work out whether it matters, prove it by building and testing, and keep a record of what is actually deployed.

The approach

Five principles, applied to every Seeq integration we maintain:

  1. Pin exactly, move deliberately. Each integration is built against one exact Seeq release, never "latest". Staying current means moving that pin on purpose, so every build is reproducible and every version number means one thing.
  2. Detect continuously. Every week, automation compares what we build against with Seeq's newest release. Nobody has to remember to look.
  3. Scope to what we use. Changes are assessed against the exact Seeq API surface our code references — so "610 classes changed" becomes "nothing we call moved".
  4. Prove it by building. The assessment is followed by a real build and test run against the new release, because the breaks that matter most are the ones inspection cannot see.
  5. Say separately what a build was made from and what it supports. "Compiled against" and "runs on" are different claims. We state both, test both, and never let one silently become the other.

How it works for our Seeq connectors

Three numbers, three claims

Every connector release carries three Seeq versions, and they answer different questions:

What it tells you
Compiled against — the Seeq Link SDK line What the connector was built from. It is the prefix of the connector's own version number (Reading an EEI Version Number).
Validated against — the Seeq platform API version The Seeq version the release was tested with, stated with every release.
Supported floor — the oldest Seeq agent it loads on The one your environment is checked against. Seeq's agent declines to load a connector whose floor is above the agent's version.

Adopting a newer Seeq SDK moves the first two. It does not move the floor: we raise that only when a connector genuinely needs something newer, and we say so when we do.

Every week

An automated check runs against each connector and against the shared foundation all our connectors are built on:

  • It finds the newest Seeq Connector SDK release and how far behind our pin is.
  • It compares the two releases only on the Seeq API surface that connector and its foundation reference, and classifies each change as a break we must fix, a change to something we never call, or an addition.
  • It builds and runs the connector's full test suite against the newest release.
  • It builds and tests against the supported floor too, so "loads on older agents" is re-proven every week rather than asserted once.
  • It checks that each connector and its shared foundation are built on the same Seeq line, so no part of a delivered connector is quietly compiled against a different Seeq than the rest.
  • It reports the floor's age against Seeq's own agent support window (below).

Findings go to one tracked record per connector, updated in place — so the state of every connector against Seeq is visible at a glance, and a quiet week is itself a result.

Every release

A release cannot ship unless the same guarantees hold at the moment of shipping:

  • The full test suite passes at the version being released and at the supported floor.
  • The build refuses a connector whose shared foundation is on a different Seeq line.
  • The release is checked against the Seeq agents we know the connector is deployed on, and any that would not load it are called out before delivery.

Where a connector serves data to Seeq, its test suite includes Seeq's own standard conformance tests, run against it on both the current and the floor Seeq line.

What is actually deployed

The floor is only as good as our knowledge of the agents it will meet. So every one of our connectors records, each time it starts, which Seeq agent version it is running on — read directly from the Seeq software the agent provides — along with the connector's own version and floor. We keep those records, and before we deliver an update to your environment we check it against your agent, not a general assumption.

If an update ever did meet an agent older than its floor, Seeq's agent declines to load it and says why in its log. The purpose of the check is that you never see that.

Where the floor sits, and why

Seeq states that its Remote Agents are compatible within a one-year window of their release. Our connectors' current floor — a Seeq SDK line from August 2025 — now sits just outside that window, and we keep it there deliberately as a starting point: it lets connectors load on somewhat older agents than Seeq itself supports, so an upgrade seldom has to wait for an agent update on your side. The weekly check reports the floor's age against that window, which gives every future decision about the floor a clear, shared reference point.

There is not yet published Seeq guidance for partners on how to set a connector's floor. We expect that conversation to develop, and we intend our practice to contribute to it.

What this means for you

When Seeq releases… A connector built into Seeq A typical custom integration An EEI connector
Is it checked against the release? Yes, inside Seeq's pipeline Usually only when something fails Yes, automatically, every week
Is it built and tested against it before it reaches you? Yes Rarely Yes, at the new line and the supported floor
Do you know which Seeq it was validated against? Yes Seldom stated Stated with every release
Is an update checked against your agent? Seeq-managed Not usually Yes, before delivery

Keeping integrations current with Seeq is our work, not yours, and it is ongoing — the reason the current generation of EEI connectors is delivered and supported as a product rather than handed over as code. It is one of the main reasons we ask customers on earlier connector releases to move to the current generation.

Next: seeing it live

Everything above happens on our side, before software reaches you. Seeq keeps its built-in features healthy with one more ingredient: live signal from where they run. Our equivalent comes through VirtualForge.

Forward-looking. This section describes direction and work in progress. It is not a commitment to a specific feature on a specific date.

With a connector connected to VirtualForge, the facts it already records and the logs it already writes become something we can analyze across deployments, not only on request. That lets us find problems before they reach you. For example:

  • An agent that is about to be left behind. One nearing the end of Seeq's support window, or one that a planned release would no longer load on. We can see it and plan the agent update with you ahead of the connector update.
  • An upgrade that would not load. Checked against your actual agent at the moment of delivery, not against our records of it.
  • A connector that is running but unhealthy. Index runs slowing, failing, or quietly doing less than they should.

This is the last piece of meeting the expectation set by Seeq's built-in features: validated before release, delivered with care, and watched in service. The pieces it builds on already exist. Connectors record what they run on at every start. The Connectors ++ monitoring capability can already publish a connector's own run health into Seeq for you to see.

Where this stands, honestly

  • Automated today: the weekly assessment, the builds and tests against the newest Seeq release and against the floor, the consistency check across a connector and its foundation, and the release-time checks.
  • Still involving an engineer: acceptance testing against a real source system, which sits inside our network and so runs on an engineer's machine rather than in automation, and the decision to adopt a newer Seeq release — which is deliberate, because timing relative to your own changes is a judgment, not a rule.
  • The Seeq SDK is the axis this automation covers. A Seeq server release can change behavior without any SDK change, and nothing on this page would detect that on its own. That is covered by acceptance testing through a live Seeq where a connector has it, and by our support commitment — not yet by the weekly automation.
  • Deployment records are new. They accumulate from each new deployment onward.