Rychlý start

Tato kapitola pomáhá vývojářům dokončit vývoj a zveřejnění své první aplikace pro TOS 7 během 5 minut.

Předpoklady

Zařízení TNAS se systémem TOS 7.0 (aktuální stabilní/beta verze) — doporučeno, ale volitelné

Nemáte hardware TNAS?

Nevadí. Aplikace TOS můžete vyvíjet bez vlastnictví fyzického zařízení TNAS. Pokud vaše vývojové prostředí splňuje doporučené nastavení (viz 8 Možnosti testovacího prostředí), můžete svou aplikaci sestavit a otestovat pomocí alternativ, jako je VM s Ubuntu 22.04 nebo vzdálené testovací zařízení.

Základní dovednosti práce s příkazovým řádkem Linuxu
Účet GitHub nebo Gitee (pro hostování kódu a integraci s vývojářskou platformou)

Pětikrokový proces zveřejňování

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

Navštivte TOS Developer Platform, zaregistrujte se a dokončete ověření vývojáře.

Krok 2: Výběr typu aplikace

Charakteristiky vaší aplikace	Doporučený typ
Nativní binárka, skripty Python (využívající systémem předinstalovaný Python 3.10), nenáročné systémové služby	Aplikace Deb
Vyžaduje izolované běhové prostředí, složité závislosti, vícekontejnerovou architekturu	Aplikace Docker

Poznámka

Běhová prostředí jazyků, jako jsou Node.js, Java a Go, nejsou v TOS předinstalovaná. Aplikace Deb na ně nemohou přímo spoléhat. Viz Kapitola 2 · Strategie architektury.

Krok 3: Výběr šablony projektu

Na základě typu vaší aplikace použijte odpovídající šablonové úložiště GitHub:

Šablonové úložiště	Způsob balení	Použitelné scénáře
Deb App Template (Single Package)	Režim jednoho balíčku	Nové aplikace postavené od nuly; všechny soubory zabaleny dohromady
Deb App Template (Dual Package)	Režim duálního balíčku	Aplikace, které již mají univerzální standardní deb balíček
Docker App Template	Docker	Kontejnerizované nasazení Docker

Poznámka

Podtyp (WebUI Internal/External/Headless) a způsob balení (jeden/duální balíček) jsou dva nezávislé rozměry a lze je libovolně kombinovat. Jeden i duální balíček podporují všechny tři podtypy.

Každé šablonové úložiště zahrnuje: kompletní strukturu adresářů, config.ini, vícejazyčné soubory, službu systemd, příkladový kód frontendu/backendu, skripty životního cyklu, skript sestavení (build.sh), konfiguraci CI/CD GitHub Actions. Kliknutím na tlačítko "Use this template" na stránce úložiště vytvoříte svůj projekt.

Krok 4: Lokální vývoj a testování

# Deb App: Build and test installation
dpkg-deb --build ./<app_root_directory> ./<appid>_<version>_<arch>.deb
sudo dpkg -i <appid>_<version>_<arch>.deb
sudo systemctl status <system_id>

# Docker App: Start testing
docker-compose up -d
curl http://localhost:<port>/health

Krok 5: Odeslání ke kontrole

Pushněte svůj kód do veřejného úložiště GitHub nebo Gitee
Vytvořte ve svém úložišti Release a nahrajte soubor balíčku jako soubor Release (podrobné požadavky na pojmenování a formát viz Kapitola 15 · Krok 3)
Vytvořte na vývojářské platformě záznam aplikace a propojte své úložiště GitHub/Gitee
Odešlete aplikaci ke kontrole; platforma automaticky stáhne balíček z vašeho Release a spustí automatizovanou validaci, po níž následuje ruční kontrola
Po schválení bude aplikace zveřejněna v TOS App Center

Poznámka: Vývojářská platforma automaticky získává balíček aplikace z vašeho GitHub/Gitee Release. Ruční nahrávání není nutné. Podrobné požadavky na formát balíčku, pojmenování a Release viz Kapitola 15 · Proces zveřejňování.

Klíčový kontrolní seznam

Před odesláním na kontrolní platformu ověřte následující položky:

config.ini je v platném formátu JSON (žádné komentáře, žádné koncové čárky, pouze dvojité uvozovky)
app.lang zahrnuje všech 14 jazyků (nepřeložené jazyky vyplněné angličtinou)
Ikona je ve formátu SVG, uložená na /images/icons/<appid>.svg
User v souboru služby systemd není root
Číslo verze je přísně zvýšeno a konzistentní napříč config.ini, DEBIAN/control a app.lang
Celý pracovní postup instalace/spuštění/zastavení/odinstalace otestován na skutečném zařízení TNAS nebo v alternativním testovacím prostředí (viz 8 Možnosti testovacího prostředí)

Nemáte hardware TNAS?
Nevadí. Aplikace TOS můžete vyvíjet a testovat bez vlastnictví fyzického zařízení TNAS. Pokud vaše vývojové prostředí splňuje doporučené nastavení (viz 8 Možnosti testovacího prostředí), alternativy, jako je VM s Ubuntu 22.04 nebo vzdálené testovací zařízení, fungují stejně dobře.

Běžné nástrahy, kterým se vyhnout

Před zahájením formálního vývoje věnujte zvláštní pozornost dvěma nejčastějším problémům napříč platformami níže, abyste se vyhnuli zamítnutí po podání:

Č. 1: Problémy s konci řádků (CRLF na LF)

Příznak: Skripty upravené ve Windows hlásí po nasazení na TOS bad interpreter: No such file or directory
Hlavní příčina: Windows ve výchozím stavu používá konce řádků CRLF; Linux rozpoznává pouze LF
Řešení: Před podáním zajistěte, aby všechny skripty a konfigurační soubory používaly konce řádků LF

# Quickly check for CRLF files in your project
grep -rl $'\r' *.sh *.py *.ini *.lang *.service *.conf 2>/dev/null

# One-click conversion (Linux/macOS)
sed -i 's/\r$//' *.sh *.py *.ini *.lang *.service *.conf

Podrobná specifikace viz Kapitola 7 · Specifikace balíčku — Konce řádků pro více platforem.

Č. 2: Chybějící závislosti Node.js

Příznak: Aplikace při spuštění hlásí node: command not found
Hlavní příčina: TOS nepředinstaluje Node.js; aplikace Deb nemohou přímo záviset na běhovém prostředí Node.js
Řešení: Použijte Go ke kompilaci statických binárek nebo použijte Python 3.10 (předinstalovaný v systému)

Další strategie viz Kapitola 2 · Strategie architektury — Řešení nepředinstalovaných závislostí.

Předpoklady​

Pětikrokový proces zveřejňování​

Klíčový kontrolní seznam​

Běžné nástrahy, kterým se vyhnout​

Č. 1: Problémy s konci řádků (CRLF na LF)​

Č. 2: Chybějící závislosti Node.js​