Back to Learn Hub

ReleasesClient

Namespace: Daisi.Protos.V1

Inheritance: ReleasesProto.ReleasesProtoClient

The Releases service manages host application updates with phased rollout support. Instead of a single global update URL, releases are tracked in the database per release group (e.g. beta, group1, production). This enables staged rollouts and rollback to previous versions. Hosts self-update via Velopack channels that map to their release group.

Setup

The Releases service is accessed via the gRPC-generated ReleasesProto.ReleasesProtoClient. You can create a client using a gRPC channel pointed at the Orc.

using Daisi.Protos.V1;
using Grpc.Net.Client;

var channel = GrpcChannel.ForAddress(DaisiStaticSettings.OrcUrl);
var releasesClient = new ReleasesProto.ReleasesProtoClient(channel);

Methods

  • CreateReleaseResponse Create(CreateReleaseRequest)
    Creates a new host release record for a given release group. Optionally activates it immediately, which deactivates any previously active release in the same group.
  • GetReleasesResponse GetReleases(GetReleasesRequest)
    Lists all releases for a given release group, ordered by date descending. Useful for viewing release history and selecting a version for rollback.
  • GetActiveReleaseResponse GetActiveRelease(GetActiveReleaseRequest)
    Returns the currently active release for a release group. Only one release can be active per group at a time. This is the release that hosts in that group will be told to update to.
  • ActivateReleaseResponse Activate(ActivateReleaseRequest)
    Activates a specific release and deactivates all others in the same group. Use this for promoting a release to a new group or rolling back to a previous version.

Release Groups

Each host can be assigned a ReleaseGroup via the Hosts management page. Hosts without an explicit group default to "production". Common groups include:

  • beta - Internal testing hosts. Receives updates first.
  • group1 / group2 - Intermediate rollout stages for gradual deployment.
  • production - All remaining hosts. The final rollout stage.

Walkthrough: Create and activate a release

var request = new CreateReleaseRequest
{
    ReleaseGroup = "beta",
    Version = "2026.02.10.1430",
    DownloadUrl = "https://daisi.blob.core.windows.net/releases/velopack/beta",
    ReleaseNotes = "Fix peer connection timeout",
    Activate = true
};

var response = await releasesClient.CreateAsync(request);
Console.WriteLine($"Created release: {response.Release.Id}");
Console.WriteLine($"Active: {response.Release.IsActive}");

Walkthrough: Roll back to a previous version

  1. List all releases for the target group to find the previous version.
  2. Activate the desired older release. Hosts will pick up the change on their next heartbeat.
// Step 1: List releases for production
var releases = await releasesClient.GetReleasesAsync(
    new GetReleasesRequest { ReleaseGroup = "production" });

foreach (var rel in releases.Releases)
{
    Console.WriteLine($"{rel.Version} - Active: {rel.IsActive} - {rel.ReleaseNotes}");
}

// Step 2: Activate the previous version
var previousRelease = releases.Releases
    .First(r => !r.IsActive); // pick the most recent inactive

var activated = await releasesClient.ActivateAsync(
    new ActivateReleaseRequest
    {
        ReleaseId = previousRelease.Id,
        ReleaseGroup = "production"
    });

Console.WriteLine($"Rolled back to: {activated.Release.Version}");

Walkthrough: Phased rollout

A typical rollout starts with beta, then progressively targets wider groups:

// 1. Push tag beta-2026.02.10 to daisi-hosts-dotnet
//    GitHub Actions auto-creates and activates for "beta"

// 2. After validating beta hosts, promote to group1
var request = new CreateReleaseRequest
{
    ReleaseGroup = "group1",
    Version = "2026.02.10.1430",
    DownloadUrl = "https://daisi.blob.core.windows.net/releases/velopack/group1",
    Activate = true
};
await releasesClient.CreateAsync(request);

// 3. Repeat for group2, then production

Tandem Releases (ORC + Host) — Deprecated

The RequiredOrcVersion field is deprecated. The one-click release pipeline (orchestrate-release.yml) now deploys the ORC before dispatching the host release, ensuring version compatibility by build order rather than runtime checks. The field remains in the proto definition for backward compatibility but is no longer populated by the automated pipeline.
SDK NuGet Publishing: When proto or SDK changes are part of a tandem release, the SDK NuGet package should be published first. Push a v* tag to daisi-sdk-dotnet to auto-publish to nuget.org, then deploy ORC, then tag the host repo. This ensures external consumers can update their SDK package reference before the new host and ORC versions roll out.

How Hosts Receive Updates

Hosts check for updates automatically on every heartbeat (approximately every 60 seconds). The Orc queries the active release for the host's release group, compares the version against the host's current version, and sends an UpdateRequiredRequest with the Velopack channel name (the release group, e.g. "beta") if an update is needed. The host's VelopackUpdateService then self-updates from https://daisi.blob.core.windows.net/releases/velopack/{channel}.

If no database release is found for a group, the Orc falls back to the legacy Daisi:MinimumHostVersion configuration for backward compatibility.