Proces zveřejňování

Podrobný pracovní postup

Krok 1: Registrace vývojářského účtu

1. Navštivte TOS Developer Platform: https://developer.terra-master.com
2. Kliknutím na tlačítko [Registrace] přejdete na stránku registračních informací
3. Použijte platnou e-mailovou adresu jako přihlašovací účet a vyplňte své jméno vývojáře (doporučuje se zachovat shodu s polem publisher v konfiguračním souboru)
4. Přečtěte si podmínky služby a souhlaste s nimi, poté kliknutím na [Potvrdit] dokončete registraci
5. Po registraci je vyžadováno ověření e-mailem; účet nabude účinnosti okamžitě, bez nutnosti ruční kontroly.

Poznámka

E-mail účtu se používá k příjmu oznámení o výsledcích kontroly, resetování hesel a dalších důležitých informací. Udržujte svůj e-mail platný.

Krok 2: Získání konfiguračních šablon a vývoj aplikace

1. Řiďte se standardními šablonami v kapitole 8 (Specifikace vývoje a konfigurace aplikací Deb) tohoto dokumentu pro napsání config.ini, app.lang, souborů služeb systemd a dalších konfigurací, nebo použijte doporučené šablonové úložiště projektu na TOS Developer Platform pro rychlou inicializaci
2. Dokončete vývoj a balení aplikace podle specifikací tohoto dokumentu
3. Proveďte lokální testování a ověření (viz kapitola 13)

Krok 3: Vytvoření Release a nahrání souborů balíčku

1. Vytvořte veřejné úložiště na GitHubu nebo Gitee

2. Vytvořte Release a nahrajte soubory balíčku

   Důležité:

   Platforma stahuje balíčky aplikací výhradně z Releases (GitHub Releases nebo Gitee Releases). Nenahrávejte soubory balíčků přímo do kořenového adresáře úložiště.

   Krok za krokem:

   • Přejděte na stránku "Releases" svého úložiště
   • Klikněte na "Create a new release" (GitHub) nebo "新建发行版" (Gitee)
   • Verze tagu: Musí přesně odpovídat poli version v config.ini (formát: xx.yy.zzz). Předpona v je volitelná, ale doporučená (např. v1.0.0 nebo 1.0.0)
   • Název Release: Doporučuje se použít stejný řetězec verze (např. v1.0.0)
   • Připojení binárek: Nahrajte soubor(y) balíčku jako soubory Release podle níže uvedených konvencí pojmenování

3. Požadavky na pojmenování a obsah souborů balíčku

   Soubor balíčku musí dodržovat níže uvedené konvence pojmenování. Čísla verzí nejsou zahrnuta v názvu souboru — určují se prostřednictvím tagu Release.

   Konvence pojmenování souborů balíčku

   Typ aplikace	Požadovaný formát souboru	Konvence pojmenování	Požadavky na obsah
   Deb (jeden balíček)	soubor .deb	<app_id>_<platform>.deb	Jeden deb balíček obsahující všechny soubory aplikace, konfiguraci a metadata
   Deb (duální balíček)	archiv .tar.gz	<app_id>_<platform>.tar.gz	Musí obsahovat <app_id>.deb (datový balíček) a <package>.deb (zdrojový balíček)
   Aplikace Docker	archiv .tar.gz	<app_id>.tar.gz	Musí obsahovat docker-compose.yml, config.ini, app.lang a soubory ikon

   Definice polí:

   • <app_id>: Musí přesně odpovídat poli id v config.ini
   • <platform>: Musí přesně odpovídat poli platform v config.ini (x86_64 nebo aarch64)
   • <package>: Musí odpovídat poli package v config.ini (pro režim duálního balíčku)
   Důležité

   • Čísla verzí nejsou zahrnuta v názvu souboru balíčku. Verze se určuje prostřednictvím tagu Release.
   • Tag Release musí přesně odpovídat poli version v config.ini.
   • Platforma validuje konzistenci verzí mezi tagem Release a config.ini.version. Neshody povedou k automatickému zamítnutí.
   • Platforma stahuje balíčky výhradně z Releases, nikoli z kořenového adresáře úložiště.
   • Jsou podporovány pouze výše uvedené formáty a konvence pojmenování. Nevyhovující názvy povedou k automatickému zamítnutí.

4. Zahrňte soubory kontrolních součtů SHA-256

   Pro každý nahraný soubor balíčku vygenerujte a připojte odpovídající soubor kontrolního součtu .sha256:

   sha256sum <package_file> > <package_file>.sha256

   Příklad: myapp_x86_64.deb → myapp_x86_64.deb.sha256

Krok 4: Vytvoření aplikace na vývojářské platformě

1. Přihlaste se na Developer Platform, klikněte na [Moje aplikace] → [Přidat aplikaci]
2. Vyplňte informace o aplikaci:
   • ID aplikace: Musí přesně odpovídat poli id v config.ini
   • Typ balíčku aplikace: Zvolte typ balíčku Docker nebo Deb
   • URL úložiště: Uveďte URL veřejného úložiště (musí být veřejné, jinak kontrola nemůže pokračovat)
3. Potvrďte a odešlete vytvoření

Krok 5: Přidání nové verze aplikace

1. Najděte cílovou aplikaci pod [Moje aplikace] a klikněte na [Správa verzí]
2. Klikněte na [Přidat verzi] a vyplňte číslo verze
   • Formát čísla verze: přísně dodržujte xx.yy.zzz (major.minor.patch)
   • Historická čísla verzí nelze znovu použít
   • Musí odpovídat poli version v config.ini
3. Po odeslání verze začíná proces zveřejňování aplikace

Požadavek na konzistenci verzí

Číslo verze, které zadáte v kroku 5, musí odpovídat:

1. Poli version v config.ini
2. Verzi tagu Release vytvořeného v kroku 3

Všechna tři musí být identická. Neshody povedou k automatickému zamítnutí.

Krok 6: Automatizovaná validace platformou

Po podání platforma automaticky provede následující kontroly:

• Validace formátu souboru (syntaxe JSON v config.ini, formát app.lang)
• Validace úplnosti polí (žádná chybějící povinná pole)
• Validace jazykového pokrytí (všech 14 jazykových uzlů přítomno)
• Validace ikony (formát SVG, shoda cesty)
• Ověření kontrolních součtů (SHA-256 odpovídá nahraným souborům)
• Validace konzistence verzí (shoda verzí config.ini / DEBIAN/control / app.lang; u aplikací Docker se kontroluje pouze konzistence verzí config.ini a app.lang, kontrola DEBIAN/control není nutná)
• Validace konzistence tagu Release s config.ini.version

Běžné příčiny selhání automatizované validace:

• config.ini obsahuje komentáře nebo chyby syntaxe
• V app.lang chybí jazykové uzly
• Ikona nenalezena nebo má nesprávný formát
• Neshoda kontrolních součtů
• Tag Release neodpovídá config.ini.version
• Název souboru balíčku nedodržuje požadovanou konvenci pojmenování

Krok 7: Ruční kontrola

Kontrolní tým kontroluje ze čtyř rozměrů (podrobnosti viz kapitola 16):

1. Úplnost konfigurace (váha 30%): Všechny požadované soubory přítomny, správný formát
2. Funkční dostupnost (váha 35%): Instalace, spuštění, provoz a odinstalace fungují bez chyb
3. Zabezpečení (váha 25%): Žádný škodlivý kód, žádná nadměrná autorizace, žádná pevně zakódovaná citlivá data
4. Dodržování předpisů (váha 10%): Soulad obsahu, popis odpovídá funkcím

Pracovní postup kontroly: Úvodní kontrola (konzistence informací, shoda úložiště) → Bezpečnostní kontrola (pracovníci technické podpory) → Testování funkční kompatibility (pracovníci podpory testování) → Komplexní kontrola (vyhrazení pracovníci kontroly)

Krok 8: Oznámení výsledku kontroly

Výsledky kontroly jsou vývojářům doručovány dvěma kanály:

• Zprávy platformy: Přihlaste se na Developer Platform a zkontrolujte stav kontroly
• Registrovaný e-mail: Výsledky kontroly jsou zasílány na e-mail použitý při registraci

Popisy stavů kontroly:

• Probíhá kontrola: Aplikace je ve frontě kontroly
• Schváleno: Aplikace prošla kontrolou a vstoupila do procesu zveřejňování
• Zamítnuto: Aplikace má problémy, které je třeba opravit; musí být opravena a znovu podána do 30 dnů
• Dobrovolně staženo: Vývojář proaktivně stáhl žádost o kontrolu

Krok 9: Oficiální zveřejnění

Po úspěšném absolvování kontroly bude aplikace uvedena v TOS App Center do 1–2 pracovních dnů:

• Uživatelé mohou aplikaci v App Center vyhledat a nainstalovat
• Vývojáři mohou pod [Moje aplikace] zkontrolovat změnu stavu aplikace na "Published"

Statistiky: Řídicí panel vývojáře zobrazuje klíčová data, jako je počet zveřejněných aplikací, celkový počet stažení aplikací a kumulativní počet podání aplikací. Průběh 3 nejnovějších zveřejňovaných aplikací je aktualizován v reálném čase.

Požadavky na úložiště

• Musí to být veřejné úložiště (GitHub nebo Gitee). Soukromá úložiště nejsou podporována.
• Soubory balíčků musí být nahrávány jako soubory Release, nikoli do kořenového adresáře úložiště.
• Prostředky úložiště musí zůstat dlouhodobě dostupné. Zveřejněné prostředky nelze mazat.
• Struktura úložiště musí odpovídat určenému rozvržení adresářů.
• Všechny binární artefakty musí být doprovázeny soubory kontrolních součtů SHA-256.

Zásady přejmenování aplikace a změny ID:

• id aplikace (v config.ini) nelze změnit po zveřejnění
• Zobrazovaný název aplikace (v app.lang) lze aktualizovat v nových verzích
• Pokud je třeba změnit id aplikace, musí být podána jako zcela nová aplikace (nové uvedení, nová kontrola)
• Stará aplikace musí projít procesem stažení z nabídky (viz oddíl 17.4)