Table of Contents

Development process and quality assurance

How DynamicWeb develops, tests, and protects releases before they reach customers, and how the development organization governs quality without a formal ISO certification

This page describes how the DynamicWeb development organization ensures that code reaching production is reviewed, tested, and safe to upgrade. It is aimed at partners and enterprise customers who need to understand the controls around our development and release process — particularly the questions that come up in IT due diligence: how testing is handled before deployment, how releases are protected before they reach customers, and how quality is governed in the absence of a formal ISO certification.

For the cadence, support windows, and release rings themselves, see the Release policy. For how bugs are classified and resolved, see the Bug fix policy and Security bug fix policy.

How code is developed

DynamicWeb works in two-week sprints starting every other Wednesday. Work is tracked in Azure DevOps as epics, features, user stories, and bugs, and prioritized through a half-year roadmap, quarterly planning, and sprint pre-planning sessions before it reaches a developer.

Source control and access

The following controls govern how source code is managed and who can access it:

  • All product source code is hosted in Azure DevOps Git, with access restricted to authorized DynamicWeb development team members
  • Authentication uses Microsoft Entra with multi-factor authentication (Microsoft Authenticator)
  • Role-based access control ensures that only designated personnel can access specific areas of the codebase
  • Repository structure and code paths drive the code review policy below

Code review and merge controls

Every change to the product source code goes through a pull request that must pass several gates before it can be merged. The following controls apply:

  • Automatic reviewer assignment by file path — Azure DevOps automatically assigns relevant developers (domain experts), product managers, and architects as required reviewers based on which files a pull request touches. There is no manual reviewer selection for critical areas
  • Architect approval is mandatory for changes to infrastructure code, security-related modules, performance-critical components, and other areas marked as architecturally sensitive
  • Multi-perspective review — most pull requests require approval from both technical reviewers (developers, architects) and business reviewers (product managers), covering both code quality and product fit
  • Unit tests must pass — pull requests are blocked from approval while any unit test is failing
  • Static analysis and security scans must pass — see the next section

Automated code policies

The codebase enforces a set of policies at the compiler and build level, not as guidelines. These include:

  • Microsoft .NET analyzers are enabled across all projects with extended analyzer rules, and the analyzer configuration is shared through a central code-analysis project so the same rules apply everywhere
  • Warnings are treated as errors (TreatWarningsAsErrors), so any analyzer or compiler warning blocks the build until it is fixed
  • Nullable reference types are enabled in the majority of the codebase, with the remaining areas being migrated incrementally
  • API baseline validation runs on every build and compares the public API surface against a baseline version. Any incompatible change blocks the build, which is how we keep the within-major compatibility promise honest
  • Automated vulnerability scanning runs against every pull request and against the repositories on a recurring schedule, so newly published CVEs are caught even when no code has changed
  • NuGet Audit runs as part of dotnet restore and dotnet build and reports any known CVEs in referenced packages. Combined with TreatWarningsAsErrors, this means a dependency with a published vulnerability blocks the build until the package is updated or the advisory is resolved — there is no separate scanner to run or report to read

The effect of these controls is that a developer cannot ship code that breaks compatibility, introduces a known CVE, suppresses a warning, or fails a unit test — these are merge blockers, not best-effort guidelines.

How code is tested before deployment

Before deployment, code is tested using two methods:

  • Automates test suites
  • Per-pull-request QA environment tests

Automated test suites

Automated test suites include:

  • Unit tests — an extensive unit-test suite covers the core platform. Tests run on every pull request, and failing tests block merge
  • Integration tests — exercise the platform together with its database and dependencies
  • End-to-end UI tests — a Playwright suite runs nightly against the latest build. Results are reviewed daily by QA, and regressions are filed as bugs and prioritized under the bug fix policy

Per-pull-request QA environments

When a developer opens a pull request, the pipeline automatically performs these steps:

  1. Builds the feature branch
  2. Deploys it to a dedicated, isolated environment
  3. Notifies QA and the assigned reviewers

This means QA can test the change in a running environment that contains only that change — separate from any other work in progress. Many production-affecting issues are caught here, before the change is merged into the release branch.

What happens between merge and a customer release

After a merge, the following steps occur before a customer release:

  1. The change becomes part of the current sprint's milestone
  2. The milestone is built and packaged as NuGet packages, with symbols, signed, and validated against the API baseline
  3. The milestone is published to the earliest release ring (R0), where it is available only to demo, test, and developer environments
  4. The milestone soaks in R0 for at least 30 days before it becomes eligible to move forward
  5. Promotion through R1 → R2 → R3 → R4 happens monthly, FIFO, so by the time a milestone reaches a production ring it has been running in non-production environments for months

The full ring mechanics, timing, and security back-port window are documented in the release policy.

How releases are protected before reaching customers

Several independent layers stand between a code change and a customer's production environment. The following table summarizes each layer and what it catches:

Layer What it catches
Pull request gates Failing tests, analyzer warnings, breaking API changes, known CVEs, missing required reviewers
Per-PR QA environment Functional and regression issues in an isolated running environment
Nightly Playwright UI runs UI and end-to-end regressions across the integrated build
API baseline validation Any incompatible change to the public .NET API surface
Ring 0 (30-day soak) Bugs that only surface in real demo, test, and developer-installation usage
Ring 2 (semi-stable) Issues found during partner staging, pre-launch validation, and customer demos
Rings 3–4 (production) Only milestones that have already passed the prior rings; critical fixes only

Critical and high-severity issues found at any layer can be hotfixed ahead of the normal cadence and back-ported to in-support rings under the bug fix policy. Security fixes are back-ported to all milestones released within the past 12 months regardless of ring, under the security bug fix policy.

This layered model — sometimes called defense in depth for releases — is what allows DynamicWeb to ship monthly minors while keeping the production rings predictable.

Governance and quality assurance without formal certification

A common question from enterprise customers and IT due diligence is how the DynamicWeb development organization governs quality and security given that the development team itself does not currently hold a formal ISO 27001 or ISO 9001 certification.

DynamicWeb operates under a comparable, documented control framework rather than a formal certification at the development-team level. The substantive controls are:

Documented, published policies with measurable SLOs

These are our documented, published policies with measurable SLOs:

Enforced technical controls

The automated code policies above are not best-effort guidelines — they are merge blockers. In governance terms, this means the development organization has technical enforcement of:

  • Backwards compatibility (API baseline validation)
  • Known-CVE-free dependencies (NuGet Audit blocks the build via warnings-as-errors, plus automated vulnerability scanning on every pull request)
  • No suppressed warnings (warnings as errors)
  • Mandatory peer and architect review (Azure DevOps branch policies)
  • No untested production code (PR-blocking unit tests)

Third-party security reviews

DynamicWeb engages external security auditors occasionally and on demand — for example to conduct independent reviews of internal security practices, deliver security-awareness training, or perform targeted assessments tied to a specific need or release. These engagements are scoped per review rather than run as a continuous service contract.

Infrastructure-tier controls

The DynamicWeb Cloud hosting environment is operated under best-practice infrastructure controls including firewalls, secure server configurations, encrypted VPN, MFA-protected access, and a cloud-native endpoint protection platform that monitors every virtual machine and container with behavioral analytics. See DynamicWeb 10 security for the full description.

Regulatory alignment

DynamicWeb supports customers in meeting the following regulatory standards relevant to commerce platforms:

Where we are still improving

A few items are still maturing and worth being transparent about for enterprise reviewers:

  • Nullable reference types are enabled across most projects but a small number of older areas are still being migrated

We mention these not as caveats to the controls above, but because honest scope is more useful to an enterprise reviewer than a polished claim of completeness.

Improve this doc
To top