Skip to content
Big Picture

Release Management Philosophy

Big Picture treats release management as a policy-driven decision process, not just a delivery mechanism.

The Traditional Model’s Limitations

Section titled “The Traditional Model’s Limitations”

Most update systems focus on how to deliver updates:

  • Downloading installers
  • Applying patches
  • Restarting applications

They assume that if an update is available, it should be installed. This works for consumer software but fails in enterprise environments where:

  • IT must approve updates before deployment
  • Different teams need different versions
  • Regulated environments require audit trails
  • Rollbacks must be immediate and reliable

Big Picture’s Approach: Decisions, Not Delivery

Section titled “Big Picture’s Approach: Decisions, Not Delivery”

Big Picture separates availability from permission from action.

Availability

Section titled “Availability”

A release is available when it’s published to a channel. This is a technical fact: the release exists, artifacts are accessible, metadata is signed.

Permission

Section titled “Permission”

Permission is determined by policy evaluation:

  • What channel is the client on?
  • What update mode applies (AUTO_INSTALL, NOTIFY_ONLY, MANAGED_BY_IT)?
  • Are there version pinning rules?
  • Is this version blocked?
  • Is a staged rollout in progress?

Action

Section titled “Action”

Action is what the client or IT system does based on the signed decision:

  • Install automatically
  • Show notification only
  • Defer to IT-managed deployment
  • Take no action

The same release can result in different actions for different clients based on policy.

Policy-Driven Updates

Section titled “Policy-Driven Updates”

Policy is the central mechanism for controlling updates:

Update Modes

Section titled “Update Modes”
  • AUTO_INSTALL: Client may install updates automatically
  • NOTIFY_ONLY: Client should notify user but not install
  • MANAGED_BY_IT: Client should not install; IT will deploy via their tools

Modes can be set globally, per-tenant, or per-product.

Version Pinning

Section titled “Version Pinning”

Tenants can pin to specific version ranges, preventing automatic updates beyond those versions while still allowing security patches within the range.

Blocklists

Section titled “Blocklists”

Specific versions can be blocked globally or per-tenant, immediately preventing their installation even if they’re available.

Staged Rollouts

Section titled “Staged Rollouts”

Releases can be rolled out gradually to a percentage of clients, enabling canary deployments and risk mitigation.

Immutability and Auditability

Section titled “Immutability and Auditability”

Releases are immutable once published:

  • Version numbers cannot be reused
  • Release metadata cannot be modified
  • Revocation creates a new event, not a modification

This ensures:

  • Audit trails: Every decision can be traced to immutable release data
  • Reproducibility: The same release always produces the same metadata
  • Compliance: Historical state can be reconstructed for audits

Vendor-Controlled Mirrors

Section titled “Vendor-Controlled Mirrors”

For regulated customers, Big Picture enables vendor-controlled mirrors that:

  • Pull signed snapshot bundles outbound-only
  • Verify signatures before serving
  • Host artifacts locally
  • Operate independently of vendor connectivity

Clients get the same signed decisions whether they connect to vendor infrastructure or local mirrors. The trust model is identical; only the delivery mechanism changes.

Integration with Existing Systems

Section titled “Integration with Existing Systems”

Big Picture does not replace existing deployment tools:

  • CI/CD systems publish releases into Big Picture
  • Artifact repositories store installers (Big Picture references them)
  • IT tools (Intune, SCCM) deploy software when MANAGED_BY_IT mode is set
  • Desktop applications integrate using Big Picture SDK to check for updates

Big Picture provides the decision layer; existing tools handle execution.

Release Lifecycle

Section titled “Release Lifecycle”
  1. Publish: Release is published to a channel with signed metadata
  2. Policy Evaluation: Clients check for updates; Big Picture evaluates policy and returns signed decisions
  3. Staged Rollout: Release may be gradually rolled out to percentage of clients
  4. Action: Clients act on decisions according to their update mode
  5. Revocation: If issues are discovered, release can be revoked (new clients won’t get it; existing installations remain)
  6. Replacement: New release replaces revoked one; clients upgrade to replacement

Why This Matters

Section titled “Why This Matters”

This philosophy enables:

  • Enterprise adoption: IT maintains control without blocking vendor updates
  • Regulatory compliance: Audit trails, policy enforcement, and self-hosting options
  • Risk mitigation: Staged rollouts, immediate revocation, version pinning
  • Operational flexibility: Different policies for different teams or environments

Big Picture makes evergreen desktop applications acceptable in environments that traditionally required manual, IT-controlled deployments.

Section titled “Related Concepts”