Windows Application Packaging vs Application Publishing

Introduktion

Windows-applikationer kan installeras och hanteras på individuella enheter eller hostas centralt och levereras till användare på distans, beroende på applikations- och infrastrukturkrav. Att välja mellan dessa modeller kräver mer än att bara jämföra teknologier. Denna artikel förklarar hur Windows-applikationspaketering fungerar, hur den skiljer sig från applikationspublicering, när varje metod är meningsfull och hur IT-team kan kombinera båda inom samma applikationsleveransstrategi.

Vad är Windows-applikationspaketering?

Windows-applikationspaketering involverar förberedelsen av en applikation samt de filer, konfiguration och metadata som den kräver för förutsägbar installation och hantering.

Istället för att manuellt konfigurera en applikation på alla målsystem kan IT-team använda ett standardiserat paket för att göra installation, konfiguration, uppdatering och borttagning mer konsekvent.

Microsofts moderna Windows-paketeringsmodell inkluderar MSIX, som möjliggör tillhandahållande av paketidentitet, förutsägbar installation och borttagning, kontrollerade uppdateringar och integration med Windows-funktioner.

Traditionella Win32-applikationer kan dra nytta av teknologier som MSI- och EXE-installatörer.

Applikationspaketering dikterar därför vad som behöver installeras, hur installation och borttagning ska ske, vilken konfiguration som tillhandahålls till användare och hur uppgraderingar kommer att äga rum. Syftet är att möjliggöra att applikationsdistributionen blir upprepningsbar och hanterbar över den målade Windows-miljön.

Vad Innehåller ett Applikationspaket?

Innehållet i ett applikationspaket beror på förpackningstekniken, applikationen själv.

En MSIX-paket till exempel, kombinerar nyttolasten av en applikation med en manifest som definierar element som paketidentitet, beroenden och funktioner. Den viktiga skillnaden här är att paketet definierar en enhet för distribution och distribution, snarare än att specificera var applikationen måste köras.

Traditionell företagsförpackning kan också innebära att man transformerar eller paketerar en befintlig installerare, lägger till konfiguration, definierar logiken för distribution och validerar det slutliga paketet innan utrullning.

Applikationspaketering är därför mer än bara att lägga applikationsfiler inuti en annan fil. Det syftar till att göra programvaruinstallationer upprepningsbara, hanterbara och stödjande.

Windows Application Packaging: Hur fungerar det?

Förpackningsarbetsflöden varierar beroende på applikationen, förpackningsformatet och hanteringsplattformen. De flesta förpackningsarbetsflöden delas dock vanligtvis upp i tre olika steg: upptäckte, paketskapande och testning före distribution.

Applikationsupptäckte och krav

Innan en ompaketering av en befintlig applikation utförs, är det avgörande för administratörer att förstå vad applikationens installationsprogram ändrar och vad applikationen kräver under körning.

Upptäcktsaktiviteter inkluderar, men är inte begränsade till:

• filer och kataloger
• registerposter
• Windows-tjänster
• körning beroenden
• miljövariabler
• filassociationer
• behörigheter
• genvägar och konfigurationsfiler

Miljön där applikationen distribueras kan vara lika viktig som installatören. En applikation som utvecklas och testas på en utvecklares arbetsstation kan agera annorlunda när den körs med standardanvändarbehörigheter, på en ren företags-Windows-avbild eller på en flermanvändarmiljö för Windows Server .

Paket skapande och konfiguration

IT-teamet förbereder sedan applikationen med lämplig paketeringsteknik för den aktuella programvaran och distributionsmodellen.

I fallet med Windows-applikationer kan detta innebära att skapa ett MSIX-paket. Detta kan involvera att lämna befintlig programvara som använder Win32 i sin MSI- eller EXE-installationsform eller att konvertera vissa applikationer till MSIX. Olika tillvägagångssätt för paketering kan ge identitet åt paketet samtidigt som programvaran får behålla element av sin befintliga installationsmodell.

Därför finns det inget enskilt förpackningsformat som passar alla Windows-applikationer. Applikationen, dess miljö och hanteringsbehov bör diktera förpackningsmetoden.

Testning och distribution

Paketen bör vara testad på rena system som återskapar den målproduktionsmiljön.

Testprocessen bör inkludera installation, första lansering, beroenden, uppdateringar, applikationsfunktionalitet och avinstallationsbeteende. Administratörer bör också kontrollera att behörigheter och användarspecifika konfigurationer hanteras korrekt, särskilt i fallet med fil- eller registeromdirigering som kan inträffa vid paketering av applikationer.

Efter validering kan paketen sedan distribueras via organisationens föredragna programvarudistributions- eller slutpunktshanteringsplattform.

Nu, låt oss ta ett steg tillbaka och klargöra en subtil men kritiskt viktig skillnad:

Applikationer paketeras och distribueras.

Separeringen av dessa funktioner är viktig eftersom den skapar en naturlig övergångspunkt för applikationspublicering.

Vad är publicering av Windows-applikationer?

Publicering av Windows-applikationer tjänar till att publicera en applikation som är installerad på centraliserad Windows-infrastruktur till auktoriserade användare via ett nätverk eller Internet.

Applikationen körs på en fjärr-Windows-värd istället för att köras på varje användares slutpunkt. I detta fall får användaren åtkomst till den fjärrkörda applikationen via en kompatibel klient, genväg eller webbläsare.

Applikation installerad på server → användare beviljad åtkomst → applikation körd på server → applikationsgränssnitt levererat till användare

Denna metod är annorlunda, eftersom administratörer istället för att installera och underhålla affärsapplikationen på varje slutpunkt, måste underhålla den på servrarna som värdar användarens session. På så sätt kan användare få tillgång till en applikation som verkar smälta in i deras arbetsmiljö sömlöst, trots att den är värd på en centraliserad infrastruktur.

Windows Application Packaging vs Application Publishing: Hur skiljer de sig åt?

Den enklaste skillnaden är:

Applikationspaketering avgör hur programvara förbereds för installation och hantering. Applikationspublicering avgör hur användare får åtkomst till programvara som körs på centraliserad infrastruktur.

Teknologierna fungerar därför på olika stadier av applikationsleverans.

Fråga	Windows-applikationspaketering	Applikationspublicering
Primärt syfte	Förbered programvara för upprepbar installation och underhåll	Ge användare åtkomst till centralt hostade applikationer
Huvud IT-fråga	Hur ska vi installera och hantera den här applikationen?	Hur ska användare få tillgång till och köra denna applikation?
Var körs appen?	På vilket system som helst som tar emot ansökan	På publicerings- eller sessionsvärden
Lokal installation på användarens slutpunkt?	Vanligtvis krävs för endpoint-distribution	Fullständig applikationsinstallation normalt inte krävs
Uppdateringar	Måste nå tillämpliga distributionsmål	Kan tillämpas centralt på publiceringsvärdar
Endpoint krav	Endpoint måste stödja den lokalt körda applikationen	Endpoint behöver främst en kompatibel åtkomstmetod
Typiskt omfång	Programvarulivscykel och hantering av slutpunkter/servrar	Centraliserad applikationsleverans
Vanliga användningsområden	Hanterade datorer, standardiserad programvara, kontrollerade utrullningar	Fjärranvändare, BYOD, äldre appar och centraliserad applikationsåtkomst

En kvalifikation: applikationspaketering dikterar inte var den nämnda programvaran används.

MSIX, MSI eller någon annan form av paket kan distribueras till en arbetsstation, bärbar dator, virtuell maskin eller server. Paketering bestämmer hur programvaran installeras och underhålls. Måldistributionen bestämmer därför var applikationen installeras.

Applikationspublicering introducerar en ytterligare arkitektonisk övervägning. Applikationen bearbetas på centraliserad infrastruktur medan dess gränssnitt levereras på fjärrslutpunkter för auktoriserade användare.

I vilket fall kan du använda applikationspaketering och publicering tillsammans?

Ja. De tar upp olika punkter i livscykeln för applikationsleverans och kan användas oberoende eller i kombination.

Överväg en organisation som har en affärsrelaterad Windows-applikation. Om den behöver köras lokalt kan den paketeras och distribueras till varje hanterad slutpunkt:

Paket → distribuera till slutpunkter → applikationen körs lokalt

Om organisationen behöver centralisera kan det paketeras eller installeras på relevanta sessionsvärdar och sedan publiceras:

Paketera eller installera → distribuera till centraliserade värdar → publicera → applikationen körs centralt

I det här fallet överges inte nödvändigtvis applikationspaketering. Det tillämpas bara på centraliserade värdar istället för varje användares enhet, vilket kan förenkla att hålla applikationen konsekvent på flera publiceringsservrar.

Applikationspaketering och applikationspublicering utesluter inte varandra: paketering standardiserar installation och underhåll av applikationen, medan publicering dikterar dess åtkomstmetod. Beroende på applikationens behov kan IT använda en metod, den andra eller båda i kombination.

I vilket fall skulle det vara bättre att använda Windows-applikationspaketering?

Microsoft Windows-applikationspaketering är mest lämplig när lokal körning är fördelaktig, och IT kan effektivt hantera enheter på vilka applikationen är värd. I sådana fall möjliggör det standardisering av installation och underhåll samtidigt som platsen för applikationskörning lämnas till användarna.

Användare behöver offlineåtkomst

Applikationer som är installerade lokalt kan fungera effektivt, även om användare inte kan få tillgång till centrala resurser, vilket ofta är fallet för mobila anställda, fältarbetare och andra nomadiska arbetare.

Förpackning hjälper IT-organisationer att säkerställa att denna metod används konsekvent genom att standardisera installation, konfiguration och uppdateringar på hanterade slutpunkter.

Applikationer beror på lokal hårdvara eller bearbetning

Vissa applikationer fungerar mest effektivt när de körs lokalt eftersom de är inneboende beroende av eller integrerade med resurserna på slutpunkten.

Lokal distribution undviker införandet av en fjärrsession mellan applikationen och resurserna, och paketering ger en upprepbar metod för att installera och konfigurera applikationen på slutpunkter som kan stödja lokal körning.

Slutpunkter är standardiserade och centralt hanterade

Förpackning är också meningsfullt i situationen där en organisation redan har en kontrollerad uppsättning Windows-enheter och en plattform för hantering av slutpunkter för att hantera dem. Om miljön huvudsakligen innehåller liknande enheter och operativsystem på samma konfigurationsnivå kan lokal applikationsdistribution och hantering inte innebära någon betydande svårighet.

Paket ger en organiserad metod för applikationshantering, vilket gör uppgiften att installera och underhålla applikationen på slutanvändarens enheter enklare. I detta scenario kan det vara onödigt att införa central exekvering och lägga till ett extra lager av komplexitet om det inte finns ett verkligt affärsbehov för en sådan åtgärd.

Därför är den centrala frågan inte huruvida applikationen kan paketeras, utan huruvida det är genomförbart att installera, uppdatera och hantera den på varje mål-enhet med hänsyn till den specifika miljön och kraven.

När gör applikationspublicering mer mening?

Applikationspublicering blir mer önskvärt när lokal installation medför onödiga drifts- eller kompatibilitetskomplexiteter.

Flera typiska situationer är värda att överväga.

Fjärr- och distribuerade användare

Fjärrarbetare, personal på filialkontor och entreprenörer arbetar inte alltid från välskötta platser eller enheter som företagsdatorer.

Applikationspublicering bevarar Windows-appen på centrala servrar samtidigt som den tillåter fjärråtkomst av auktoriserade användare, vilket avlastar administratörer från bördan att replikera applikationsmiljön på varje fjärrenhet.

BYOD och blandade slutpunktsmiljöer

En Windows-applikation kanske inte nödvändigtvis körs på varje typ av enhet som en viss organisation använder.

Publicering av applikationer avkopplar körmiljön från slutanvändaren. Genom att använda en sådan metod kan en individ få tillgång till en centralt hostad Windows-app via en godkänd webbläsare eller klient på sin maskin, som annars inte skulle kunna köra applikationen.

Denna strategi är idealisk för både bring-your-own-device (BYOD) och andra miljöer där det finns flera operativsystem för slutpunkter.

Legacy Windows-applikationer

Arvprogrammeringar kan komplicera distributionsinsatser genom att förlita sig på operativsystemberoenden, åldrande komponenter och svåra konfigurationsbegränsningar.

Att centralisera applikationen kan hjälpa till att minska miljöer där IT måste få programvaran att fungera. Det löser inte nödvändigtvis problem med applikationskompatibilitet, men det kan begränsa dessa problem till kontrollerade Windows-värdar, istället för en spridd samling av slutpunkter.

Detta kan förenkla standardiseringen kring åtkomst till äldre applikationer när en organisation arbetar mot en långsiktig moderniseringsplan.

Applikationer som kräver frekventa uppdateringar

Frequent changes to an application make its local deployment more difficult, especially when the number of endpoints increases.

Med applikationspublicering uppdaterar administratörer applikationen i de relevanta centrala värdarna. Användare får sedan tillgång till den uppdaterade applikationen utan att behöva uppdatera programvaran på alla slutpunkter.

Processen är särskilt fördelaktig när många användare är beroende av samma applikation men inte behöver använda den lokalt.

Hur ska IT-team välja mellan paketering och publicering?

IT-team bör fokusera på applikationens driftskrav snarare än valet av teknik.

Om lokal installation är lätt att underhålla, är dina slutpunkter noggrant kontrollerade och användarna behöver offline- eller hårdvaruberoende funktioner, ger paketerad slutpunktsdistribution mest mening. Om dina användare är spridda, är dina slutpunkter heterogena, lokal installation är utmanande eller applikationen är lättare att hålla uppdaterad centralt, kan applikationspublicering minska övervakningen av slutpunktsförvaltning.

Många företag kommer att behöva båda modellerna. Ditt hanterade skrivbordsanvändare kan få lokalt distribuerade applikationer, men entreprenörer, distansarbetare eller de som använder ohanterade enheter kan få centralt publicerad åtkomst till specifik affärsprogramvara.

Valet blir mycket tydligare om IT avskiljer tre frågor.

1. Hur ska applikationen paketeras och underhållas?
2. Var ska applikationen distribueras och köras?
3. Hur ska användare få tillgång till det?

Att betrakta förpackning, distribution och åtkomst som separata beslut förhindrar att två fundamentalt olika teknologier jämförs som om de vore samma lösning.

Hur kan TSplus Remote Access vara en lösning?

Organisationer som vill ha centraliserad leverans av Windows-applikationer utan att distribuera hela applikationen till varje slutpunkt kan använda TSplus Remote Access att publicera valda Windows-applikationer eller tillhandahålla fullständiga fjärrskrivbord från centraliserad Windows-infrastruktur.

Administratörer kan tilldela applikationer till specifika användare eller grupper och ge åtkomst genom stödda fjärrklienter eller webbläsarbaserade HTML5-anslutningar. Detta gör applikationspublicering till ett alternativ för organisationer som stöder fjärranvändare, BYOD-miljöer eller Windows-applikationer som är enklare att underhålla centralt.

Slutsats

Windows-applikationspaketering ger ett upprepningsbart sätt att installera, konfigurera och underhålla programvara, medan applikationspublicering ger användare tillgång till applikationer som körs på centraliserad infrastruktur. Ingen av metoderna ersätter den andra i grunden, och båda kan ingå i samma applikationsleveransstrategi.

Den rätta modellen beror på applikationskrav, hantering av slutpunkter och användartillgångsbehov. Genom att överväga förpackning, distributionsplats och åtkomst separat kan IT-team besluta om en applikation ska köras lokalt, centralt eller genom en kombination av båda modellerna.