Back to Pixy Overview
Stage 6 · Pixy Platform

Testing & Release Safety

A paying customer’s Revit session is not a place to discover a regression. The test and release discipline is built around proving behaviour rather than the presence of a string — and around failure modes that have actually happened.

Behavioural testsGitHub Actions CISecret-leak gatePost-deploy smoke testFeature flags
Overview 1The Revit Add-in 2Licensing & Anti-Piracy 3The License Server 4AI Suite, Pixels & Cloud 5Growth Engineering 6Testing & Release Safety

Philosophy

Behavioural tests over source-text checks

Asserting that a file contains a string proves nothing about what the service does. The tests here exercise real behaviour: webhook rewrites run against mock Postgres pools, the AI-proxy redirect walker runs against local mock servers and against real TLS, and the Telegram shim runs against a fake 401.

The route-registration test

This one guards against a real past incident: a module-scope error silently unregistered six routes while the service still reported healthy. Nothing crashed, nothing alerted — the endpoints were simply gone.

The test loads the real module in a no-listen mode with an ephemeral key and asserts every critical route is present in the Express table.

Pipeline

CI that fails closed

  • GitHub Actions verifies only — Render owns deploys — pinned to the exact Node major that Render runs, so CI cannot pass on a runtime production does not use.
  • A step that fails closed if any real production credential reaches CI.
  • An npm audit gate on critical and high findings.
  • A separate job that spins up a throwaway Postgres, applies the real security-lockdown migration, and proves the anon role can no longer call the sensitive function — the RLS fix from Stage 3 is re-verified on every run, not trusted to stay fixed.

Shipping

Post-deploy verification and release discipline

A post-deploy smoke test probes the live service unauthenticated and distinguishes 401 (route present, auth required — pass) from 404 (route missing — fail), and can assert the deployed build SHA. That distinction is exactly what catches the silent-unregistration failure mode in production rather than in a support ticket.

  • Deploys are never automatic.
  • Feature flags default to safe.
  • Migrations are additive and reversible.
  • The deployed build is verified by a health marker — Render can lag a push by 30 to 90 minutes, so elapsed time is never assumed to mean shipped.

In summary

Engineering problems worth calling out

  • Making one obfuscated DLL run across every Revit 2025–2027 build without recompilation, via multi-targeting, an assembly-resolve shim and a post-build reference-patcher.
  • A licensing system that resists piracy yet never locks out a paying user offline.
  • Closing an RLS privilege-escalation oracle exploitable with a public anon key, with a migration that verifies its own success and aborts otherwise.
  • A credential-safe AI proxy that re-derives secrets per redirect hop.
  • Leak-proof discount mechanics using per-recipient signed tokens and idempotent, in-place licence mutation.
  • Turning Revit’s single-threaded, context-bound API into a host for modeless, previewable, async tools without freezing the UI or crashing the host.

Pixy is a live commercial product. This case study describes the production system as deployed.

Previous
Growth Engineering