Налаштування збірки та підписання Linux-десктоп-застосунків

Виробнича збірка десктоп-застосунку для Linux

Розробники десктоп-застосунків під Linux стикаються з дилемою: який формат пакета обрати, щоб охопити максимум користувачів, і як автоматизувати збірку, щоб не витрачати дні на рутину. AppImage, Snap, Flatpak, .deb, .rpm — кожен вимагає своєї конфігурації, і помилка на старті відкидає команду назад. Ми допомагаємо налаштувати єдиний пайплайн збірки та підписання для всіх популярних форматів, щоб ви зосередилися на коді, а не на упаковці.

Проблеми, які вирішуємо

1. Фрагментація форматів. Користувачі Ubuntu чекають Snap, Fedora — Flatpak, а консерватори — .deb або .rpm. Випускати один формат — означає втратити частину аудиторії. Ми налаштовуємо збірку всіх форматів з одного вихідника, заощаджуючи до 40% часу на реліз.

2. Підписання та довіра. Непідписані пакети викликають попередження безпеки. GPG-підписання вирішує проблему, але вимагає правильного налаштування ключів та інтеграції в CI/CD. Наш досвід — понад 50 проєктів з підписанням — гарантує, що пакети будуть прийняті в магазинах без відмов.

3. Автоматизація випуску. Ручна збірка кожного релізу — шлях до помилок. Ми впроваджуємо автоматичні збірки на кожен коміт у GitLab CI або GitHub Actions з публікацією в Snap Store та Flathub.

Як ми це робимо: кейс Electron-застосунку

Нещодавно налаштовували збірку для Electron-застосунку з React. Вихідний код на TypeScript, збірка через electron-builder. Наша конфігурація охопила всі цільові формати:

---
# electron-builder.yml
linux:
  target:
    - target: AppImage
    - target: deb
    - target: rpm
  icon: build/icons
  category: Utility
deb:
  depends:
    - libnotify4
    - libxtst6
    - libnss3
appImage:
  systemIntegration: ask
---

Для Snap та Flatpak додали окремі маніфести. Розібрали повний цикл: від локальної збірки до публікації. У результаті застосунок доступний у Snap Store та Flathub за 3 робочі дні.

AppImage: self-contained файл

AppImage — найпростіший формат для користувача: завантажив, зробив chmod +x, запустив. Без встановлення та прав root. Ідеально для швидкого поширення через сайт.

Snap-пакет

Snap вимагає написання snapcraft.yaml та реєстрації в магазині. Ми використовуємо strict confinement з мінімальними привілеями.

---
# snapcraft.yaml
name: appname
version: '1.0.0'
summary: Application Name
description: |
  Full description.
grade: stable
confinement: strict
apps:
  appname:
    command: usr/lib/appname/appname
    plugs:
      - desktop
      - network
      - home
parts:
  appname:
    plugin: dump
    source: dist/linux-unpacked
    source-type: local

Публікація однією командою:

snapcraft login snapcraft upload appname_1.0.0_amd64.snap --release=stable 

Докладніше про збірку Snap-пакетів читайте в офіційній документації Snapcraft.

Flatpak

Flatpak вимагає вказання runtime та finish-args. Приклад для GNOME-застосунку:

<!-- com.company.AppName.yml -->
app-id: com.company.AppName
runtime: org.freedesktop.Platform
runtime-version: '23.08'
sdk: org.freedesktop.Sdk
command: appname
finish-args:
  - --share=network
  - --socket=x11
  - --socket=wayland
  - --filesystem=home
modules:
  - name: appname
    buildsystem: simple
    build-commands:
      - install -Dm755 appname /app/bin/appname

Як працює GPG-підписання пакетів?

Підписання GPG-ключем гарантує, що пакет створено саме вами і не було змінено. Snapcraft та Flathub перевіряють підпис перед публікацією. Для .deb та .rpm підпис підвищує довіру користувачів при встановленні зі сторонніх репозиторіїв. Приклад підписання:

# Підписання deb-пакета
dpkg-sig --sign builder AppName_1.0.0_amd64.deb
# Підписання RPM
rpm --addsign AppName-1.0.0.x86_64.rpm

Згідно з документацією Snapcraft, підписання обов'язкове для стабільного каналу.

Як автоматизувати збірку для всіх форматів Linux?

Ми будуємо CI/CD-пайплайн, який на кожен коміт збирає всі вибрані формати. Стек: GitLab CI або GitHub Actions, Docker для відтворюваності, скрипти для публікації. Середній проєкт з трьома форматами економить близько 20 годин на місяць на ручних операціях.

Що обрати: Snap чи Flatpak?

Якщо ваш застосунок щільно інтегрується з Gnome і вимагає доступу до користувацьких даних, Flatpak швидше запускається і споживає менше ресурсів (на 30% менше пам'яті порівняно з Snap). Snap переважніший для IoT та серверів, оскільки підтримує фонові сервіси та автоматичні оновлення з коробки. Для масового десктопа обидві платформи рівнозначні.

Процес роботи

1. Аналіз — вивчаємо ваш застосунок, його залежності та цільову аудиторію.
2. Проєктування — обираємо формати, налаштовуємо CI/CD (GitLab, GitHub Actions).
3. Реалізація — пишемо конфіги, підключаємо підписання, тестуємо локально.
4. Тестування — перевіряємо встановлення та запуск на Ubuntu, Fedora, Arch Linux.
5. Деплой — публікуємо в Snap Store, Flathub та/або на ваш сайт.

Що входить у роботу

• Конфігурація збірки для вибраних форматів (AppImage, deb, rpm, Snap, Flatpak).
• Налаштування GPG-підписання та інтеграція в пайплайн.
• CI/CD-скрипти для автоматичної збірки та публікації.
• Документація щодо процесу релізу.
• Доступи до магазинів (Snap Store, Flathub) з налаштованими правами.
• Навчання команди (1 година онлайн).
• 30 днів технічної підтримки після здачі.

Терміни орієнтовно

• Налаштування одного формату: від 1 до 3 робочих днів.
• Повна збірка (AppImage + deb + rpm + Snap + Flatpak) з CI/CD: від 5 до 7 днів.
• Час залежить від складності застосунку та вимог до магазинів. Вартість розраховується індивідуально.

Досвід нашої команди — понад 5 років у збірці Linux-застосунків, понад 50 успішних проєктів. Ми гарантуємо, що зібрані пакети пройдуть модерацію магазинів і будуть готові до поширення. Зв'яжіться з нами для оцінки вашого проєкту. Замовте консультацію, щоб дізнатися оптимальну конфігурацію збірки під ваші завдання.