)
)
Introduzione
Le applicazioni Windows possono essere installate e gestite su singoli endpoint o ospitate centralmente e consegnate agli utenti da remoto, a seconda dei requisiti dell'applicazione e dell'infrastruttura. Scegliere tra questi modelli richiede più di un semplice confronto tra tecnologie. Questo articolo spiega come funziona il packaging delle applicazioni Windows, come si differenzia dalla pubblicazione delle applicazioni, quando ciascun approccio ha senso e come i team IT possono combinare entrambi all'interno della stessa strategia di consegna delle applicazioni.
Cosa è il Packaging delle Applicazioni Windows?
La confezione dell'applicazione Windows comporta la preparazione di un'applicazione e dei file, della configurazione e dei metadati necessari per un'installazione e una gestione prevedibili.
Invece di configurare manualmente un'applicazione su tutti i sistemi target, i team IT possono utilizzare un pacchetto standardizzato per rendere l'installazione, la configurazione, l'aggiornamento e la rimozione più coerenti.
Il moderno modello di imballaggio di Windows di Microsoft include MSIX, che consente la fornitura di identità del pacchetto, installazione e rimozione prevedibili, aggiornamenti controllati e integrazione con le funzionalità di Windows.
Le applicazioni Win32 tradizionali possono sfruttare tecnologie come gli installer MSI ed EXE.
Il packaging dell'applicazione quindi determina cosa deve essere installato, come deve avvenire l'installazione e la rimozione, quale configurazione è fornita agli utenti e come avverranno gli aggiornamenti. Il suo obiettivo è rendere il deployment dell'applicazione ripetibile e gestibile nell'ambiente Windows di destinazione.
Cosa Contiene un Pacchetto di Applicazione?
Il contenuto di un pacchetto applicativo dipende dalla tecnologia di imballaggio, dall'applicazione stessa.
Un pacchetto MSIX ad esempio, combina il payload di un'applicazione con un manifesto che definisce elementi come l'identità del pacchetto, le dipendenze e le capacità. La distinzione importante qui è che il pacchetto definisce un'unità di distribuzione e distribuzione, piuttosto che specificare dove l'applicazione deve essere eseguita.
Il confezionamento tradizionale per le imprese può anche comportare la trasformazione o l'imballaggio di un installer esistente, l'aggiunta di configurazioni, la definizione della logica per il deployment e la convalida del pacchetto finale prima del rilascio.
L'imballaggio delle applicazioni è quindi più di un semplice inserimento di file di applicazione all'interno di un altro file. Mira a rendere l'installazione del software ripetibile, gestibile e supportabile.
Imballaggio delle applicazioni Windows: come funziona?
I flussi di lavoro di imballaggio variano a seconda dell'applicazione, del formato di imballaggio e della piattaforma di gestione. Tuttavia, la maggior parte dei flussi di lavoro di imballaggio è generalmente suddivisa in tre fasi diverse: scoperta, creazione del pacchetto e test prima del deployment.
Scoperta delle applicazioni e requisiti
Prima di eseguire un ripackaging di un'applicazione esistente, è fondamentale che gli amministratori comprendano cosa modifica l'installer dell'applicazione e cosa richiede l'applicazione durante l'esecuzione.
Le attività di scoperta includono, ma non si limitano a:
- file e directory
- voci di registro
- Servizi di Windows
- dipendenze di runtime
- variabili di ambiente
- associazioni di file
- permessi
- scorciatoie e file di configurazione
L'ambiente in cui l'applicazione è distribuita può essere altrettanto importante quanto l'installatore. Un'applicazione che è sviluppata e testata su una workstation di sviluppo può comportarsi in modo diverso quando viene eseguita utilizzando permessi utente standard, su un'immagine Windows aziendale pulita o su un ambiente multi-utente di Windows Server .
Creazione e configurazione del pacchetto
I team IT preparano quindi l'applicazione utilizzando la tecnologia di imballaggio appropriata per il software e il modello di distribuzione forniti.
Nel caso delle applicazioni Windows, questo potrebbe significare creare un pacchetto MSIX. Ciò potrebbe comportare il mantenimento del software esistente che utilizza Win32 nella sua forma di installer MSI o EXE o la conversione di alcune applicazioni in MSIX. Approcci diversi al packaging possono fornire identità per il pacchetto consentendo al software di mantenere elementi del suo modello di installazione esistente.
Pertanto, non esiste un formato di imballaggio unico che si adatti a tutte le applicazioni Windows. L'applicazione, il suo ambiente e le esigenze di gestione dovrebbero determinare l'approccio all'imballaggio.
Test e distribuzione
I pacchetti dovrebbero essere testato su sistemi puliti che replicano l'ambiente di produzione target.
Il processo di test dovrebbe includere installazione, primo avvio, dipendenze, aggiornamenti, funzionalità dell'applicazione e comportamento di disinstallazione. Gli amministratori dovrebbero anche verificare che i permessi e le configurazioni specifiche per gli utenti siano gestiti correttamente, specialmente nel caso di reindirizzamento di file o registro che può verificarsi durante il confezionamento delle applicazioni.
Dopo la convalida, i pacchetti possono quindi essere distribuiti tramite la piattaforma di distribuzione software o gestione degli endpoint preferita dall'organizzazione.
Ora, facciamo un passo indietro e chiarifichiamo una sottile ma estremamente importante distinzione:
Le applicazioni vengono confezionate e poi distribuite.
La separazione di queste funzioni è importante perché crea un punto di transizione naturale per la pubblicazione delle applicazioni.
Cosa è la Pubblicazione di Applicazioni Windows?
Pubblicazione di applicazioni Windows serve a pubblicare un'applicazione installata su un'infrastruttura Windows centralizzata per utenti autorizzati tramite una rete o Internet.
L'applicazione viene eseguita su un host Windows remoto invece di essere eseguita su ciascun endpoint dell'utente. In questo caso, all'utente viene fornito accesso all'applicazione eseguita in remoto tramite un client compatibile, un collegamento o un browser web.
Applicazione installata sul server → utente autorizzato all'accesso → applicazione eseguita sul server → interfaccia dell'applicazione consegnata all'utente
Questo approccio è diverso, poiché invece di installare e mantenere l'applicazione aziendale su ogni endpoint, gli amministratori sono tenuti a mantenerla sui server che ospitano la sessione dell'utente. In questo modo, gli utenti possono accedere a un'applicazione che sembra integrarsi perfettamente nel loro ambiente di lavoro, nonostante sia ospitata su un'infrastruttura centralizzata.
Windows Application Packaging vs Application Publishing: Qual è la differenza?
La distinzione più semplice è:
Il packaging delle applicazioni determina come il software è preparato per l'installazione e la gestione. La pubblicazione delle applicazioni determina come gli utenti accedono al software in esecuzione su un'infrastruttura centralizzata.
Le tecnologie operano quindi in diverse fasi della consegna delle applicazioni.
| Domanda | Imballaggio delle applicazioni Windows | Pubblicazione delle applicazioni |
|---|---|---|
| Scopo principale | Preparare il software per un'installazione e manutenzione ripetibile | Consenti agli utenti di accedere ad applicazioni ospitate centralmente |
| Domanda principale IT | Come dovremmo installare e gestire questa applicazione? | Come dovrebbero gli utenti accedere e utilizzare questa applicazione? |
| Dove viene eseguita l'app? | Su qualsiasi sistema riceva l'applicazione | Sul server di pubblicazione o host di sessione |
| Installazione locale sul punto finale dell'utente? | Di solito richiesto per il deployment degli endpoint | Installazione completa dell'applicazione normalmente non richiesta |
| Aggiornamenti | Deve raggiungere gli obiettivi di distribuzione applicabili | Può essere applicato centralmente agli host di pubblicazione |
| Requisiti per l'endpoint | L'endpoint deve supportare l'applicazione eseguita localmente. | L'endpoint ha principalmente bisogno di un metodo di accesso compatibile. |
| Ambito tipico | Gestione del ciclo di vita del software e degli endpoint/server | Consegna centralizzata delle applicazioni |
| Casi d'uso comuni | PC gestiti, software standardizzati, distribuzioni controllate | Utenti remoti, BYOD, app legacy e accesso centralizzato alle applicazioni |
Un'osservazione: l'imballaggio delle applicazioni non determina dove il software in questione viene utilizzato.
MSIX, MSI o qualsiasi altra forma di pacchetto può essere distribuita a una workstation, laptop, macchina virtuale o server. Il packaging determina come il software viene installato e assistito. La distribuzione target quindi determina dove l'applicazione viene installata.
La pubblicazione delle applicazioni introduce un'ulteriore considerazione architettonica. I processi dell'applicazione si svolgono su un'infrastruttura centralizzata mentre la sua interfaccia viene fornita su endpoint remoti per utenti autorizzati.
In quale caso potresti utilizzare insieme l'imballaggio e la pubblicazione delle applicazioni?
Sì. Affrontano diversi aspetti nel ciclo di vita della consegna delle applicazioni e possono essere utilizzati indipendentemente o in combinazione.
Considera un'organizzazione che ha un'applicazione Windows per la linea di business. Se deve essere eseguita localmente, può essere confezionata e distribuita a ogni endpoint gestito:
Pacchetto → distribuisci ai punti finali → l'applicazione viene eseguita localmente
Se l'organizzazione ha bisogno di centralizzare, potrebbe essere confezionato o installato sui relativi host di sessione e poi pubblicato:
Pacchetto o installa → distribuisci su host centralizzati → pubblica → l'applicazione viene eseguita centralmente
In questo caso, il confezionamento delle applicazioni non viene necessariamente abbandonato. Viene semplicemente applicato a host centralizzati invece che a ogni dispositivo dell'utente, il che può semplificare il mantenimento dell'applicazione coerente su più server di pubblicazione.
Il confezionamento delle applicazioni e la pubblicazione delle applicazioni non sono mutuamente esclusivi: il confezionamento standardizza l'installazione e la manutenzione dell'applicazione, mentre la pubblicazione ne determina il metodo di accesso. A seconda delle esigenze dell'applicazione, l'IT può utilizzare un metodo, l'altro o entrambi in combinazione.
In quale caso sarebbe meglio utilizzare il packaging delle applicazioni Windows?
L'imballaggio delle applicazioni Microsoft Windows è più appropriato quando l'esecuzione locale è vantaggiosa e l'IT può gestire efficacemente i dispositivi su cui l'applicazione è ospitata. In tali casi, consente la standardizzazione dell'installazione e della manutenzione, lasciando agli utenti la scelta della posizione di esecuzione dell'applicazione.
Gli utenti hanno bisogno di accesso offline
Le applicazioni installate localmente possono operare in modo efficace, anche se gli utenti non riescono ad accedere alle risorse centrali, cosa che accade spesso per i dipendenti mobili, i lavoratori sul campo e altri lavoratori nomadi.
Il packaging aiuta le organizzazioni IT a garantire che questo approccio venga utilizzato in modo coerente standardizzando installazione, configurazione e aggiornamenti sui punti finali gestiti.
Le applicazioni dipendono dall'hardware locale o dall'elaborazione
Alcune applicazioni funzionano in modo più efficace quando vengono eseguite localmente perché sono intrinsecamente dipendenti dalle risorse del punto finale o integrate con esse.
Il deployment locale evita l'introduzione di una sessione remota tra l'applicazione e le risorse, e il packaging fornisce un metodo ripetibile per installare e configurare l'applicazione sugli endpoint in grado di supportare l'esecuzione locale.
Gli endpoint sono standardizzati e gestiti centralmente
Il packaging ha senso anche nella situazione in cui un'organizzazione dispone già di un insieme controllato di dispositivi Windows e di una piattaforma di gestione degli endpoint per gestirli. Se l'ambiente contiene per lo più dispositivi e sistemi operativi simili allo stesso livello di configurazione, il deployment e la gestione delle applicazioni locali potrebbero non presentare difficoltà significative.
I pacchetti offrono un approccio organizzato alla gestione delle applicazioni, il che rende più facile il compito di installare e mantenere l'applicazione sui dispositivi degli utenti finali. In questo scenario, l'introduzione dell'esecuzione centrale potrebbe non essere necessaria e aggiungere un ulteriore livello di complessità a meno che non ci sia un reale bisogno aziendale per tale misura.
Pertanto, la domanda chiave non è se l'applicazione possa essere confezionata, ma se sia fattibile installarla, aggiornarla e gestirla su ogni dispositivo target considerando l'ambiente e i requisiti specifici.
Quando ha più senso la pubblicazione delle applicazioni?
La pubblicazione delle applicazioni diventa più desiderabile quando l'installazione locale comporta complessità operative o di compatibilità eccessive.
Diverse situazioni tipiche meritano considerazione.
Utenti Remoti e Distribuiti
I lavoratori remoti, il personale degli uffici periferici e i contrattisti non lavorano sempre da luoghi o dispositivi ben gestiti come i PC aziendali.
La pubblicazione delle applicazioni preserva l'app Windows sui server centrali consentendo accesso remoto da parte degli utenti autorizzati, sollevando così gli amministratori dall'onere di replicare l'ambiente applicativo su ogni dispositivo remoto.
BYOD e ambienti misti di endpoint
Un'applicazione Windows potrebbe non essere eseguita necessariamente su ogni tipo di dispositivo utilizzato da un'organizzazione particolare.
La pubblicazione delle applicazioni separa l'ambiente di esecuzione dall'utente finale. Utilizzando un tale metodo, un individuo può accedere a un'app Windows ospitata centralmente tramite un browser o un client approvato sul proprio computer, che altrimenti non sarebbe in grado di eseguire l'applicazione.
Questa strategia è ideale sia per l'uso di dispositivi personali (BYOD) che per altri ambienti in cui ci sono più sistemi operativi per endpoint.
Applicazioni Windows Legacy
Applicazioni legacy può complicare gli sforzi di distribuzione facendo affidamento su dipendenze del sistema operativo, componenti obsoleti e vincoli di configurazione difficili.
Centralizzare l'applicazione può aiutare a ridurre gli ambienti in cui l'IT deve far funzionare il software. Non risolverà necessariamente i problemi di compatibilità delle applicazioni, ma può limitare tali problemi a host Windows controllati, invece di una vasta collezione di endpoint.
Questo può semplificare la standardizzazione dell'accesso alle applicazioni legacy mentre un'organizzazione lavora verso un piano di modernizzazione a lungo termine.
Applicazioni che richiedono aggiornamenti frequenti
Cambiamenti frequenti a un'applicazione rendono più difficile il suo deployment locale, specialmente quando aumenta il numero di endpoint.
Con la pubblicazione delle applicazioni, gli amministratori aggiornano l'applicazione nei relativi host centrali. Gli utenti accedono quindi all'applicazione aggiornata senza dover aggiornare il software su tutti i punti finali.
Il processo è particolarmente vantaggioso quando molti utenti dipendono dalla stessa applicazione ma non devono utilizzarla localmente.
Come dovrebbero le squadre IT scegliere tra imballaggio e pubblicazione?
I team IT dovrebbero considerare i requisiti operativi dell'applicazione piuttosto che la scelta della tecnologia.
Se l'installazione locale è facile da mantenere, i tuoi endpoint sono strettamente controllati e gli utenti necessitano di funzionalità offline o dipendenti dall'hardware, il deployment degli endpoint confezionato ha più senso. Se i tuoi utenti sono distribuiti, i tuoi endpoint sono eterogenei, l'installazione locale è difficile o l'applicazione è più facile da mantenere centralmente, la pubblicazione dell'applicazione può ridurre il sovraccarico della gestione degli endpoint.
Molte aziende richiederanno entrambi i modelli. Gli utenti del desktop gestito potrebbero ricevere applicazioni distribuite localmente, ma i collaboratori, i telelavoratori o coloro che utilizzano dispositivi non gestiti potrebbero avere accesso pubblicato centralmente a software aziendali specifici.
La scelta diventa molto più chiara se l'IT separa tre domande.
- Come dovrebbe essere confezionata e mantenuta l'applicazione?
- Dove dovrebbe essere distribuita e eseguita l'applicazione?
- Come dovrebbero gli utenti accedervi?
Guardare al packaging, al deployment e all'accesso come decisioni separate impedisce di confrontare due tecnologie fondamentalmente diverse come se fossero la stessa soluzione.
Come può TSplus Remote Access essere una soluzione?
Le organizzazioni che desiderano una distribuzione centralizzata delle applicazioni Windows senza dover installare l'applicazione completa su ogni endpoint possono utilizzare TSplus Remote Access per pubblicare applicazioni Windows selezionate o fornire desktop remoti completi da un'infrastruttura Windows centralizzata.
Gli amministratori possono assegnare applicazioni a utenti o gruppi specifici e fornire accesso tramite client remoti supportati o connessioni HTML5 basate su browser. Questo rende la pubblicazione delle applicazioni un'opzione per le organizzazioni che supportano utenti remoti, ambienti BYOD o applicazioni Windows che sono più facili da gestire centralmente.
Conclusione
La confezione delle applicazioni Windows fornisce un modo ripetibile per installare, configurare e mantenere il software, mentre la pubblicazione delle applicazioni offre agli utenti l'accesso a applicazioni che vengono eseguite su un'infrastruttura centralizzata. Nessuno dei due approcci sostituisce intrinsecamente l'altro e entrambi possono far parte della stessa strategia di distribuzione delle applicazioni.
Il modello giusto dipende dai requisiti dell'applicazione, dalla gestione degli endpoint e dalle esigenze di accesso degli utenti. Considerando separatamente il packaging, la posizione di distribuzione e l'accesso, i team IT possono decidere se un'applicazione dovrebbe essere eseguita localmente, centralmente o attraverso una combinazione di entrambi i modelli.
TSplus Remote Access Prova Gratuita
Alternativa definitiva a Citrix/RDS per accesso a desktop/app. Sicuro, conveniente, on-premises/cloud
)
)
)
