Skip to content

How We Build, Release and Deliver

This is the path a change takes from an engineer's desk to software running in your environment. Two things are worth knowing up front:

  • Continuous integration is in place today. Building, testing, validating, reporting and releasing run through an automated pipeline, the same way for every product.
  • Continuous delivery is being built, deliberately. Today delivery into your environment is a managed, largely manual step. We are automating it, but only on top of a foundation that has already proven itself — because delivery is the step that touches your systems.

The path at a glance

  Develop ─► Test ─► Validate ─► Report ─► Release ─► Publish ─►  Deliver  ─►  Observe
  └──────────── continuous integration: in place today ─────────────┘  └─ managed today ─┘ └ planned ┘
                                                                         └─ automated: being built ─┘

Continuous integration — in place today

Develop. Every product's source lives in version control, and every product builds with the same shared conventions and release tooling. A fix to how we build or release is made once and inherited everywhere, so products do not drift apart in how carefully they are made.

Test. An automated, self-contained test suite runs in the build. For our Seeq connectors that includes building and testing against the current Seeq release and against the oldest Seeq agent the connector supports — see Validating Seeq Integrations Against Seeq Continuous Delivery.

Validate. Acceptance testing runs the product against a real source system. Where that system sits inside our network, acceptance runs on an engineer's machine rather than in automation, and produces the same kind of record.

Report. A test run produces an evidence bundle: the results of both tiers, a hash of every file tested, and who ran it on which machine. It is written to versioned, encrypted storage under a 365-day retention lock, so "this version was tested" is something we can retrieve rather than recall. Separately, a weekly report shows where each Seeq connector stands against Seeq's newest release.

Release. A release is an explicit, deliberate action — never a side effect of a merge — and runs in GitHub Actions. The release build is the gate: a failing test, a connector built on an inconsistent Seeq line, or a failed build at the supported floor stops the release rather than annotating it. A passing release is tagged, so the exact source of every shipped version is recoverable. The pipeline holds no stored cloud credentials; it proves its identity for each run and receives short-lived, narrowly scoped access.

Publish and manage. Released products are published as immutable, integrity-verified packages to a managed artifact repository (AWS CodeArtifact). The shared libraries our products are built on are versioned and published the same way, so every release records exactly what it was built from. Release evidence is kept in AWS S3 alongside.

Delivery today — managed, and manual by design

Delivery is where software meets your environment, so today it is performed by EEI (or with you), with each critical step kept in as few hands as possible.

  • Licensing. Our products are licensed with signed licenses bound to the specific host they run on, and they work fully offline — no call home is needed to run. The signing keys are held in a managed secret store, never on a laptop or in source code; production and development keys are separate; and issuing a license requires a narrowly scoped role. Every issuance is recorded.
  • Getting the right release. The release you receive is the one your agreement entitles you to, retrieved from the same immutable repository the pipeline published it to.
  • Installing and upgrading. Installation and upgrades are carried out by or with EEI. Before an upgrade reaches a Seeq connector's host, we check that host's Seeq agent against the release's supported floor, and every connector records what it is running on each time it starts.

This is deliberately conservative. The steps with the most consequence — keys, licenses, and what reaches your environment — are the last ones we automate, not the first.

Continuous delivery — being built

Automated delivery arrives through VirtualForge and the Connectors ++ capabilities, as automatic updates governed by your entitlements:

  • VirtualForge decides; the repository delivers. Whether a host may update, to which version or channel, and when, is an entitlement decision made by VirtualForge. The software itself still comes from the same immutable, integrity-verified repository.
  • Whole-bundle updates. An update replaces a product as a unit, never file by file, so a host is never left half-upgraded.
  • Never push what your agent would refuse. Every Seeq connector bundle already declares the oldest Seeq agent it supports, so the updater can compare a candidate release against your agent before sending it, not after.
  • Your choice. Automatic updates are something you enable, not something that happens to you.

Where that stands: the release format, the bundle's machine-readable manifest, and the update design are already part of every release we ship. The automated update behavior itself is not live yet.

When it is, we will have a full CI/CD pipeline: the same guarantees that gate a release today will gate what reaches your environment.

Building the foundation first

We could have automated delivery sooner. We chose to put the pieces in place that make automated delivery safe before turning it on:

  • Every release already carries its own description: version, what it was built against, and the oldest agent it supports.
  • Identity without standing secrets: the pipeline holds no long-lived cloud keys.
  • Evidence from the start: test evidence is retained, attributable and hash-verified.
  • One pipeline for every product, so an improvement reaches all of them at once.
  • Entitlements and licensing in one model, so automated updates can reuse the same decision about what you are entitled to.

Where this stands, honestly

Status
Automated build, test, and release gate In place
Build and test against current Seeq and the supported floor In place
Immutable, versioned package repository In place
Retained, attributable test evidence In place where the acceptance run happens; making it mandatory for every release is committed work
Signed, host-bound, offline licensing with restricted issuance In place
Installation and upgrade Managed by EEI, manual by design
Automatic, entitlement-governed updates Being built
Live diagnosis of deployed connectors through VirtualForge Planned — see what comes next