Windows Application Packaging vs Application Publishing

Introduksjon

Windows-applikasjoner kan installeres og administreres på individuelle endepunkter eller hostes sentralt og leveres til brukere eksternt, avhengig av applikasjons- og infrastrukturkrav. Å velge mellom disse modellene krever mer enn å sammenligne teknologier. Denne artikkelen forklarer hvordan Windows-applikasjonspakking fungerer, hvordan det skiller seg fra applikasjonspublisering, når hver tilnærming gir mening, og hvordan IT-team kan kombinere begge innenfor den samme applikasjonsleveringsstrategien.

Hva er Windows-applikasjonspakking?

Windows-applikasjonspakking involverer forberedelse av en applikasjon og filene, konfigurasjonen og metadataene den trenger for forutsigbar installasjon og administrasjon.

I stedet for å manuelt konfigurere en applikasjon på alle målsystemer, kan IT-team bruke en standardisert pakke for å gjøre installasjon, konfigurasjon, oppdatering og fjerning mer konsistent.

Microsofts moderne Windows-pakkemodell inkluderer MSIX, som muliggjør levering av pakkeidentitet, forutsigbar installasjon og fjerning, kontrollerte oppdateringer og integrasjon med Windows-funksjoner.

Tradisjonelle Win32-applikasjoner kan dra nytte av teknologier som MSI- og EXE-installasjoner.

Applikasjonspakking dikterer derfor hva som må installeres, hvordan installasjon og fjerning skal skje, hvilken konfigurasjon som tilbys brukerne, og hvordan oppgraderinger vil finne sted. Målet er å gjøre applikasjonsdistribusjon gjentakelig og håndterbar på tvers av det målrettede Windows-miljøet.

Hva inneholder en applikasjonspakke?

Innholdet i en applikasjonspakke avhenger av pakkingsteknologien, applikasjonen selv.

An MSIX-pakke for eksempel kombinerer nyttelasten til en applikasjon med et manifest som definerer elementer som pakkeidentitet, avhengigheter og muligheter. Den viktige forskjellen her er at pakken definerer en enhet for distribusjon og distribusjon, i stedet for å spesifisere hvor applikasjonen må kjøre.

Tradisjonell bedriftspakking kan også innebære å transformere eller pakke en eksisterende installatør, legge til konfigurasjon, definere logikken for distribusjon og validere den endelige pakken før utrulling.

Applikasjonspakking er derfor mer enn bare å legge applikasjonsfiler inn i en annen fil. Den har som mål å gjøre programvareinstallasjon gjentakelig, håndterbar og støttbar.

Windows-applikasjonspakking: Hvordan fungerer det?

Pakking arbeidsflyter varierer avhengig av applikasjonen, pakkeforformatet og administrasjonsplattformen. Imidlertid er de fleste pakkingsarbeidsflyter generelt delt opp i tre forskjellige faser: oppdagelse, pakkeopprettelse og testing før distribusjon.

Applikasjonsoppdagelse og krav

Før man utfører en repakking av en eksisterende applikasjon, er det avgjørende for administratorer å forstå hva applikasjonens installasjonsprogram endrer og hva applikasjonen krever under kjøring.

Oppdagelsesaktiviteter inkluderer, men er ikke begrenset til:

• filer og kataloger
• registeroppføringer
• Windows-tjenester
• kjøring avhengigheter
• miljøvariabler
• filtilknytninger
• tillatelser
• snarveier og konfigurasjonsfiler

Miljøet applikasjonen distribueres til kan være like viktig som installatøren. En applikasjon som er utviklet og testet på en utviklers arbeidsstasjon, kan oppføre seg annerledes når den kjøres med standard brukerrettigheter, på et rent bedrifts-Windows-bilde eller på en flermanns Windows Server-miljø .

Pakkeopprettelse og konfigurasjon

IT-teamene forbereder deretter applikasjonen ved å bruke passende pakkingsteknologi for den gitte programvaren og distribusjonsmodellen.

I tilfelle av Windows-applikasjoner kan dette bety å opprette en MSIX-pakke. Dette kan innebære å la eksisterende programvare som bruker Win32 være i sin MSI- eller EXE-installeringsform, eller å konvertere noen applikasjoner til MSIX. Ulike tilnærminger til pakking kan gi identitet til pakken samtidig som programvaren får beholde elementer fra sin eksisterende installasjonsmodell.

Derfor finnes det ikke et enkelt pakkeformat som passer for alle Windows-applikasjoner. Applikasjonen, dens miljø og administrasjonsbehov bør diktere pakkemetoden.

Testing og distribusjon

Pakker bør være testet på rene systemer som replikerer målproduksjonsmiljøet.

Testprosessen bør inkludere installasjon, første oppstart, avhengigheter, oppdateringer, applikasjonsfunksjonalitet og avinstallasjonsatferd. Administratorer bør også sjekke at tillatelser og brukerspesifikke konfigurasjoner håndteres korrekt, spesielt i tilfelle av fil- eller registeromdirigering som kan oppstå når applikasjoner pakkes.

Etter validering kan pakkene deretter distribueres via organisasjonens foretrukne programvarefordelings- eller endepunktsadministrasjonsplattform.

Nå, la oss ta et skritt tilbake og klargjøre en subtil, men kritisk viktig distinksjon:

Applikasjoner pakkes, og deretter distribueres

Separasjonen av disse funksjonene er viktig fordi den skaper et naturlig overgangspunkt for applikasjonspublisering.

Hva er publisering av Windows-applikasjoner?

Publisering av Windows-applikasjoner tjenester for å publisere en applikasjon som er installert på sentralisert Windows-infrastruktur til autoriserte brukere via et nettverk eller Internett.

Applikasjonen kjøres på en ekstern Windows-vert i stedet for å bli kjørt på hver brukers endepunkt. I dette tilfellet får brukeren tilgang til den eksternt kjørte applikasjonen gjennom en kompatibel klient, snarvei eller nettleser.

Applikasjon installert på server → bruker tildelt tilgang → applikasjon utført på server → applikasjonsgrensesnitt levert til bruker

Denne tilnærmingen er annerledes, ettersom administratorer i stedet for å installere og vedlikeholde forretningsapplikasjonen på hver sluttbruker, må vedlikeholde den på serverne som huser brukerens økt. Slik kan brukerne få tilgang til en applikasjon som ser ut til å smelte sømløst inn i arbeidsmiljøet deres, til tross for at den er vert på sentralisert infrastruktur.

Windows Application Packaging vs Applikasjonspublisering: Hvordan skiller de seg?

Den enkleste distinksjonen er:

Applikasjonspakking bestemmer hvordan programvare forberedes for installasjon og administrasjon. Applikasjonspublisering bestemmer hvordan brukere får tilgang til programvare som kjører på sentralisert infrastruktur.

Teknologiene opererer derfor på forskjellige stadier av applikasjonslevering.

Spørsmål	Windows applikasjonspakking	Applikasjonspublisering
Primært formål	Forbered programvare for gjentakbar installasjon og vedlikehold	Gi brukere tilgang til sentralt hostede applikasjoner
Hoved IT-spørsmål	Hvordan skal vi installere og administrere denne applikasjonen?	Hvordan skal brukere få tilgang til og kjøre denne applikasjonen?
Hvor kjører appen?	På hvilket som helst system som mottar applikasjonen	På publiserings- eller øktvert
Lokal installasjon på brukerens sluttpunkt?	Vanligvis nødvendig for distribusjon av endepunkter	Fullstendig applikasjonsinstallasjon er vanligvis ikke nødvendig
Oppdateringer	Må nå gjeldende distribusjonsmål	Kan anvendes sentralt for publiseringsverter
Krav til endepunkt	Endpoint må støtte den lokalt kjørte applikasjonen	Endpoint trenger primært en kompatibel tilgangsmetode
Typisk omfang	Programvarelivssyklus og administrasjon av sluttpunkter/servere	Sentralisert applikasjonslevering
Vanlige bruksområder	Administrerte PC-er, standardisert programvare, kontrollerte utrullinger	Fjernbrukere, BYOD, eldre apper og sentralisert applikasjonstilgang

En kvalifikasjon: applikasjonspakking dikterer ikke hvor nevnt programvare opereres.

MSIX, MSI eller en annen form for pakke kan distribueres til en arbeidsstasjon, bærbar datamaskin, virtuell maskin eller server. Pakking bestemmer hvordan programvaren installeres og vedlikeholdes. Målrettet distribusjon bestemmer derfor hvor applikasjonen installeres.

Applikasjonspublisering introduserer en ytterligere arkitektonisk vurdering. Applikasjonsprosessene kjører på sentralisert infrastruktur mens grensesnittet leveres på eksterne endepunkter for autoriserte brukere.

I hvilke tilfeller kan du bruke applikasjonspakking og publisering sammen?

Ja. De tar for seg forskjellige punkter i livssyklusen for applikasjonslevering og kan brukes uavhengig av hverandre eller i kombinasjon.

Vurder en organisasjon som har en forretningsapplikasjon for Windows. Hvis den må kjøres lokalt, kan den pakkes og distribueres til hver administrert sluttpunkt:

Pakke → distribuer til endepunkter → applikasjonen kjører lokalt

Hvis organisasjonen trenger å sentralisere, kan det pakkes eller installeres på relevante sesjonsverter og deretter publiseres:

Pakke eller installer → distribuer til sentraliserte verter → publiser → applikasjonen kjører sentralt

I dette tilfellet er ikke applikasjonspakking nødvendigvis forlatt. Det brukes bare på sentraliserte verter i stedet for hver brukers enhet, noe som kan forenkle opprettholdelsen av applikasjonen på flere publiseringsservere.

Applikasjonspakking og applikasjonspublisering er ikke gjensidig utelukkende: pakking standardiserer applikasjonsinstallasjonen og vedlikeholdet, mens publisering dikterer tilgangsmetoden. Avhengig av applikasjonens behov kan IT bruke én metode, den andre, eller begge i kombinasjon.

I hvilke tilfeller ville det være bedre å bruke Windows-applikasjonspakking?

Microsoft Windows-applikasjonspakking er mest hensiktsmessig når lokal kjøring er gunstig, og IT kan effektivt administrere enheter som applikasjonen er vert for. I slike tilfeller muliggjør det standardisering av installasjon og vedlikehold, samtidig som det lar brukerne bestemme hvor applikasjonen skal kjøres.

Brukere trenger offline tilgang

Applikasjoner installert lokalt kan fungere effektivt, selv om brukerne ikke har tilgang til sentrale ressurser, noe som ofte er tilfelle for mobile ansatte, feltarbeidere og andre nomadiske arbeidere.

Pakking hjelper IT-organisasjoner med å sikre at denne tilnærmingen brukes konsekvent ved å standardisere installasjon, konfigurasjon og oppdateringer på administrerte endepunkter.

Applikasjoner avhenger av lokal maskinvare eller behandling

Noen applikasjoner fungerer mest effektivt når de kjøres lokalt fordi de er iboende avhengige av eller integrert med ressursene til endepunktet.

Lokal distribusjon unngår introduksjonen av en ekstern økt mellom applikasjonen og ressursene, og pakking gir en gjentakelig metode for å installere og konfigurere applikasjonen på sluttpunkter som kan støtte lokal kjøring.

Endepunkter er standardisert og sentralt administrert

Pakking gir også mening i situasjonen der en organisasjon allerede har et kontrollert sett med Windows-enheter og en plattform for administrasjon av endepunkter for å håndtere dem. Hvis miljøet hovedsakelig inneholder lignende enheter og operativsystemer på samme konfigurasjonsnivå, kan lokal distribusjon og administrasjon av applikasjoner ikke by på noen betydelig vanskelighet.

Pakker gir en organisert tilnærming til applikasjonsadministrasjon, noe som gjør oppgaven med å installere og vedlikeholde applikasjonen på sluttbrukerens enheter enklere. I dette scenariet kan det å introdusere sentral utførelse være unødvendig og legge til et ekstra lag av kompleksitet med mindre det er et faktisk forretningsbehov for et slikt tiltak.

Derfor er det sentrale spørsmålet ikke om applikasjonen kan pakkes, men om det er mulig å installere, oppdatere og administrere den på hver mål-enhet med tanke på det spesifikke miljøet og kravene.

Når gir applikasjonspublisering mer mening?

Applikasjonspublisering blir mer ønskelig når lokal installasjon medfører unødvendige drifts- eller kompatibilitetskompleksiteter.

Flere typiske situasjoner er verdt å vurdere.

Fjern- og distribuerte brukere

Fjernarbeidere, ansatte på filialkontorer og kontraktører jobber ikke alltid fra godt administrerte steder eller enheter som bedrifts-PC-er.

Applikasjonspublisering bevarer Windows-appen på sentrale servere samtidig som den tillater fjernaksess av autoriserte brukere, og dermed fritar administratorer fra byrden med å replikere applikasjonsmiljøet på hver fjern enhet.

BYOD og blandede sluttpunktmiljøer

En Windows-applikasjon vil ikke nødvendigvis kjøre på alle typer enheter som en bestemt organisasjon bruker.

Publisering av applikasjoner frikobler kjøreomgivelsene fra sluttbrukeren. Ved å bruke en slik metode kan en person få tilgang til en sentralt hostet Windows-app via en godkjent nettleser eller klient på sin maskin, som ellers ikke ville vært i stand til å kjøre applikasjonen.

Denne strategien er ideell for både bring-your-own-device (BYOD) og andre miljøer der det er flere sluttpunkt-operativsystemer.

Legacy Windows-applikasjoner

Legacy-applikasjoner kan komplisere distribusjonsinnsatsen ved å være avhengig av operativsystemavhengigheter, aldrende komponenter og vanskelige konfigurasjonsbegrensninger.

Å sentralisere applikasjonen kan bidra til å redusere miljøer der IT må få programvaren til å fungere. Det vil ikke nødvendigvis løse problemer med applikasjonskompatibilitet, men det kan begrense disse problemene til kontrollerte Windows-verter, i stedet for en omfattende samling av sluttpunkter.

Dette kan forenkle standardiseringen rundt tilgang til eldre applikasjoner mens en organisasjon arbeider mot en langsiktig moderniseringsplan.

Applikasjoner som krever hyppige oppdateringer

Hyppige endringer i en applikasjon gjør lokal distribusjon mer vanskelig, spesielt når antallet endepunkter øker.

Med applikasjonspublisering oppdaterer administratorer applikasjonen i de relevante sentrale vertene. Brukere får deretter tilgang til den oppdaterte applikasjonen uten å måtte oppdatere programvaren på alle endepunkter.

Prosessen er spesielt fordelaktig når mange brukere er avhengige av den samme applikasjonen, men ikke trenger å bruke den lokalt.

Hvordan bør IT-team velge mellom pakking og publisering?

IT-team bør se på applikasjonens driftskrav i stedet for valg av teknologi.

Hvis lokal installasjon er enkel å vedlikeholde, er endepunktene dine strengt kontrollerte, og brukerne trenger offline- eller maskinvareavhengige funksjoner, gir pakket distribusjon av endepunkter mest mening. Hvis brukerne dine er distribuerte, er endepunktene dine heterogene, lokal installasjon er utfordrende, eller applikasjonen er enklere å holde oppdatert sentralt, kan applikasjonspublisering redusere overheaden ved endepunktsadministrasjon.

Mange bedrifter vil kreve begge modeller. Dine administrerte skrivebordsbrukere kan få lokalt distribuerte applikasjoner, men entreprenører, hjemmearbeidere eller de som bruker ikke-administrerte enheter kan få sentralt publisert tilgang til spesifik programvare.

Valget blir mye klarere hvis IT avkobler tre spørsmål.

1. Hvordan skal applikasjonen pakkes og vedlikeholdes?
2. Hvor skal applikasjonen distribueres og kjøres?
3. Hvordan skal brukere få tilgang til det?

Å se på emballasje, distribusjon og tilgang som separate beslutninger forhindrer to fundamentalt forskjellige teknologier fra å bli sammenlignet som om de var den samme løsningen.

Hvordan kan TSplus Remote Access være en løsning?

Organisasjoner som ønsker sentralisert levering av Windows-applikasjoner uten å distribuere den komplette applikasjonen til hver sluttbruker kan bruke TSplus Remote Access for å publisere valgte Windows-applikasjoner eller gi fullstendige eksterne skrivebord fra sentralisert Windows-infrastruktur.

Administratorer kan tildele applikasjoner til spesifikke brukere eller grupper og gi tilgang gjennom støttede eksterne klienter eller nettleserbaserte HTML5-tilkoblinger. Dette gjør applikasjonspublisering til et alternativ for organisasjoner som støtter eksterne brukere, BYOD-miljøer eller Windows-applikasjoner som er enklere å vedlikeholde sentralt.

Konklusjon

Windows-applikasjonspakking gir en gjentakelig måte å installere, konfigurere og vedlikeholde programvare på, mens applikasjonspublisering gir brukere tilgang til applikasjoner som kjører på sentralisert infrastruktur. Ingen av tilnærmingene erstatter den andre, og begge kan være en del av den samme applikasjonsleveringsstrategien.

Den riktige modellen avhenger av applikasjonskrav, administrasjon av endepunkter og brukerens tilgangsbehov. Ved å vurdere pakking, distribusjonssted og tilgang separat, kan IT-team bestemme om en applikasjon skal kjøre lokalt, sentralt eller gjennom en kombinasjon av begge modeller.