Проверка версий и каналы обновлений (stable/beta)

Введение

Не все пользователи должны получать одно и то же обновление одновременно — часто нужно разделить аудиторию на каналы: стабильный (stable) канал для большинства пользователей, получающих только тщательно протестированные релизы, и бета-канал (beta) для энтузиастов или внутренней команды, готовых тестировать более свежую, потенциально менее стабильную функциональность раньше остальных. В статье разберём, как организовать несколько каналов обновлений поверх механизма QtIFW, разобранного в предыдущей статье.

Концепция

QtIFW не имеет встроенной «из коробки» концепции множественных каналов обновления — реализация строится на организации нескольких отдельных репозиториев (один на канал) и переключении между ними через настройку RemoteRepositories в конфигурации приложения, обновляемой самим приложением программно в зависимости от того, к какому каналу подписан конкретный пользователь. Переключение канала пользователем обычно реализуется через настройку в самом приложении, которая модифицирует список используемых репозиториев maintenance tool перед следующей проверкой обновлений.

Пример кода: Проверка версий и

# Генерация ОТДЕЛЬНЫХ репозиториев для каждого канала из соответствующего набора пакетов
repogen -p packages_stable --update-new-components repo_stable
repogen -p packages_beta --update-new-components repo_beta

# Каждый репозиторий размещается на сервере по своему собственному пути
rsync -avz repo_stable/ user@updates.mycompany.com:/var/www/myapp-updates/stable/
rsync -avz repo_beta/ user@updates.mycompany.com:/var/www/myapp-updates/beta/

// updatechannelmanager.h — переключение канала обновлений из самого приложения
#pragma once
#include <QSettings>
#include <QProcess>
#include <QCoreApplication>

class UpdateChannelManager
{
public:
    enum class Channel { Stable, Beta };

    static Channel currentChannel()
    {
        const QString saved = QSettings().value("updates/channel", "stable").toString();
        return (saved == "beta") ? Channel::Beta : Channel::Stable;
    }

    static void setChannel(Channel channel)
    {
        QSettings settings;
        settings.setValue("updates/channel", channel == Channel::Beta ? "beta" : "stable");

        // Перенастраиваем maintenance tool на использование нужного репозитория
        const QString repositoryUrl = (channel == Channel::Beta)
            ? "https://updates.mycompany.com/myapp-updates/beta"
            : "https://updates.mycompany.com/myapp-updates/stable";

        const QString maintenanceToolPath = QCoreApplication::applicationDirPath()
                                           + "/MyAppUpdater";

        QProcess::execute(maintenanceToolPath,
            {"--addRepository", repositoryUrl, "--removeRepository", oppositeRepositoryUrl(channel)});
    }

private:
    static QString oppositeRepositoryUrl(Channel channel)
    {
        return (channel == Channel::Beta)
            ? "https://updates.mycompany.com/myapp-updates/stable"
            : "https://updates.mycompany.com/myapp-updates/beta";
    }
};

// Использование в настройках приложения
void SettingsDialog::onChannelComboBoxChanged(int index)
{
    const auto newChannel = (index == 1) ? UpdateChannelManager::Channel::Beta
                                          : UpdateChannelManager::Channel::Stable;

    if (newChannel != UpdateChannelManager::currentChannel()) {
        UpdateChannelManager::setChannel(newChannel);
        QMessageBox::information(this, "Канал обновлений изменён",
            "Изменение вступит в силу при следующей проверке обновлений.");
    }
}

Пояснения к коду

Каждый канал обновлений генерируется как полностью независимый репозиторий через отдельный вызов repogen с собственным набором пакетов (packages_stable/packages_beta) — это позволяет, например, иметь в бета-репозитории компонент с более новой версией, чем в стабильном, при том что оба репозитория физически независимы и размещены по разным путям на сервере, не конфликтуя друг с другом.

UpdateChannelManager::setChannel() сохраняет выбор канала в QSettings для последующего отображения текущего состояния в интерфейсе настроек, и одновременно вызывает maintenance tool с флагами --addRepository/--removeRepository, программно изменяя список репозиториев, которые maintenance tool будет опрашивать при следующей проверке обновлений — этот вызов происходит через QProcess::execute() синхронно, поскольку операция достаточно быстрая (просто изменение локальной конфигурации, без сетевого обращения на этом этапе).

Подводные камни

• Переключение с бета на стабильный канал не означает автоматический «откат» уже установленных бета-версий компонентов до стабильной версии. Если пользователь уже обновился до бета-версии 1.2.0-beta, а затем переключился на стабильный канал, где максимальная доступная версия — 1.1.0, maintenance tool, скорее всего, не предложит «понижение» версии автоматически (зависит от конкретной настройки версионирования) — для поддержки реального откат-сценария нужна отдельная, явно спроектированная логика, не предоставляемая автоматически базовым механизмом QtIFW.
• Несогласованность номеров версий между каналами, если бета-версии не следуют чёткой, однозначно сравнимой схеме версионирования относительно стабильных релизов (например, использование суффикса -beta, который не все инструменты сравнения версий корректно интерпретируют как «более новую, но менее стабильную» версию) — нужна явная, продуманная схема версионирования (semver с пре-релизными суффиксами), совместимая с тем, как именно QtIFW сравнивает строки версий внутри Updates.xml.
• Раздельное поддержание двух (или более) параллельных наборов пакетов для разных каналов увеличивает нагрузку на процесс релиза. Команде нужно явно решить, является ли бета-канал просто «более ранним» срезом того же кода (что технически проще поддерживать, синхронизируя пакеты автоматически из CI) или полноценной отдельной веткой с собственной независимой логикой возможных отличий — выбор архитектуры процесса релиза существенно влияет на сложность поддержки множественных каналов в долгосрочной перспективе.
• Отсутствие явного предупреждения пользователю о потенциальной нестабильности бета-канала перед переключением — пользователь, случайно выбравший бета-канал из любопытства, может столкнуться с реальными багами и составить негативное мнение о качестве продукта в целом, не понимая, что находится на тестовом канале — UI переключения каналов должен явно и недвусмысленно предупреждать о характере и рисках выбора нестабильного канала, как частично показано во всплывающем сообщении в примере, но в реальном продукте формулировка должна быть заметно более явной о потенциальных рисках.