Software packaging
Nu inventa nimic: patru reguli pe care AppCloud365 le urmează când construiește un pachet
Un pachet care eșuează în tăcere la distribuție costă mai mult decât unul care nu este construit niciodată. De ce verificăm hash-uri, nu ghicim niciodată comenzi, luăm tooling doar din surse oficiale și raportăm codurile de ieșire nemodificate.
Există un tip de eroare deosebit de scump în împachetarea de zi cu zi: pachetul care pare reușit. Jobul spune „gata”, distribuția spune „instalat”, iar după trei zile se dovedește că dezinstalarea nu a funcționat niciodată sau că installerul nu a fost cel dorit. Când am proiectat AppCloud365, a contat mai mult pentru noi ca așa ceva să nu se poată întâmpla decât ca fiecare aplicație să treacă la apăsarea unui buton. Din asta au ieșit patru reguli.
Regula 1: Nicio descărcare fără hash
Fiecare manifest din catalogul WinGet conține suma de control SHA-256 a installerului. AppCloud365 descarcă fișierul pe server, calculează hash-ul în timpul recepției și îl compară cu manifestul. Dacă nu se potrivește, fișierul este eliminat și jobul eșuează cu un mesaj clar. Fișierul nu este livrat niciodată în acest caz, nici măcar „pentru verificare”.
La asta se adaugă reguli care se simt doar când lipsesc: descărcări doar prin HTTP și HTTPS, fără credențiale în URL-uri, fără conexiuni către intervale de rețea private, limite de dimensiune, limite de timp, iar numele de fișiere care vin din URL sau de la server sunt curățate înainte să atingă discul.
Regula 2: Comenzile nu se ghicesc
A doua regulă sună banal și este cea mai grea: comenzile de instalare și dezinstalare vin exclusiv din datele manifestului și din ce se știe cu certitudine despre familia de installere.
Un MSI primește msiexec.exe /i cu parametrii silențioși. Dezinstalarea există doar dacă este prezent un ProductCode GUID valid; atunci sună msiexec.exe /x "{GUID}" /qn /norestart. Installerele Inno Setup și Nullsoft primesc parametrii impliciți documentați ai framework-ului lor dacă manifestul nu numește alții. Un installer EXE fără parametru cunoscut primește o comandă fără parametru, marcată explicit ca nesigură. Iar dacă nu se poate deriva nicio comandă de dezinstalare, asistentul o spune: „Comanda de dezinstalare nu a putut fi determinată automat.” Atunci introduci una sau confirmi explicit că pachetul nu are.
Ce nu există: un ProductCode pe un installer EXE care se transformă în tăcere în msiexec /x. Ar fi o presupunere, iar presupunerile nu valorează nimic într-un script de distribuție.
Regula 3: Tooling doar din surse oficiale
PSAppDeployToolkit și Microsoft Win32 Content Prep Tool sunt software terț. AppCloud365 nu le descarcă niciodată la rulare. Un bootstrap separat preia versiunea stabilă curentă din depozitele oficiale, verifică starea de lansare, dimensiunea fișierului, conținutul arhivei și fișierele obligatorii și le stochează în afara directorului web. Pre-lansările sunt sărite. Dacă toolingul lipsește, interfața arată opțiunile de împachetare afectate ca indisponibile în loc să construiască un pachet fără toolkit.
Regula 4: Codurile de ieșire nu se îndulcesc
Wrapperul nativ fără PSADT rulează comanda confirmată și transmite rezultatul mai departe. Codurile de ieșire 0, 3010 (repornire recomandată) și 1641 (repornire inițiată) contează ca succes. Orice alt cod este raportat nemodificat ca eșec. Nu există „necunoscut înseamnă în regulă”. Fără o comandă de dezinstalare confirmată, Uninstall.ps1 produce în mod deliberat o eroare cu mesajul că nu s-a putut determina comanda, astfel încât raportarea distribuției să arate lipsa.
Același principiu se aplică și construirii: o rulare care eșuează nu produce niciun pachet. Primul mesaj relevant al toolului ajunge în mesajul de eroare al jobului, nu într-un jurnal pe care nu îl deschide nimeni.
De ce asta costă viteză și este totuși mai rapid
Aceste reguli înseamnă că AppCloud365 nu împachetează fiecare aplicație complet automat. Un program portabil fără date de manifest primește doar descărcarea originală; un installer exotic cere o comandă de dezinstalare manuală. Este intenționat. Timpul pe care îl costă este timp pe care un packager ar trebui să îl investească oricum, doar mai devreme și vizibil. Timpul pe care îl economisește este noaptea în care două sute de dispozitive raportează un pachet care doar părea că a funcționat.
Toate imaginile prezintă aplicația reală cu date demo fictive, în versiunea în limba engleză.