Windows Application Packaging vs Publication d'Application

Introduction

Les applications Windows peuvent être installées et gérées sur des points de terminaison individuels ou hébergées de manière centralisée et livrées aux utilisateurs à distance, en fonction des exigences de l'application et de l'infrastructure. Choisir entre ces modèles nécessite plus que de comparer des technologies. Cet article explique comment fonctionne l'emballage des applications Windows, en quoi cela diffère de la publication d'applications, quand chaque approche a du sens et comment les équipes informatiques peuvent combiner les deux dans la même stratégie de livraison d'applications.

Qu'est-ce que l'emballage d'application Windows ?

L'emballage d'application Windows implique la préparation d'une application ainsi que des fichiers, de la configuration et des métadonnées nécessaires pour une installation et une gestion prévisibles.

Plutôt que de configurer manuellement une application sur tous les systèmes cibles, les équipes informatiques peuvent utiliser un package standardisé pour rendre l'installation, la configuration, la mise à jour et la suppression plus cohérentes.

Le modèle de packaging moderne de Windows de Microsoft inclut MSIX, qui permet la fourniture d'une identité de package, une installation et une suppression prévisibles, des mises à jour contrôlées et une intégration avec les fonctionnalités de Windows.

Les applications Win32 traditionnelles peuvent tirer parti de technologies telles que les installateurs MSI et EXE.

L'emballage des applications dicte donc ce qui doit être installé, comment l'installation et la désinstallation doivent se dérouler, quelle configuration est fournie aux utilisateurs et comment les mises à jour auront lieu. Son objectif est de permettre un déploiement d'applications répétable et gérable dans l'environnement Windows cible.

Que contient un package d'application ?

Le contenu d'un package d'application dépend de la technologie d'emballage, de l'application elle-même.

Un package MSIX par exemple, combine la charge utile d'une application avec un manifeste qui définit des éléments tels que l'identité du package, les dépendances et les capacités. La distinction importante ici est que le package définit une unité de distribution et de déploiement, plutôt que de spécifier où l'application doit s'exécuter.

L'emballage traditionnel des entreprises peut également impliquer la transformation ou l'emballage d'un installateur existant, l'ajout de configurations, la définition de la logique de déploiement et la validation du package final avant le déploiement.

L'emballage d'application est donc plus qu'un simple fait de mettre des fichiers d'application à l'intérieur d'un autre fichier. Il vise à rendre l'installation de logiciels répétable, gérable et supportable.

Packaging d'application Windows : comment cela fonctionne-t-il ?

Les workflows d'emballage varient en fonction de l'application, du format d'emballage et de la plateforme de gestion. Cependant, la plupart des workflows d'emballage sont généralement divisés en trois étapes différentes : découverte, création de package et test avant le déploiement.

Découverte des applications et exigences

Avant de procéder à un reconditionnement d'une application existante, il est essentiel que les administrateurs comprennent ce que l'installateur de l'application modifie et ce que l'application nécessite pendant son exécution.

Les activités de découverte comprennent, mais ne se limitent pas à :

• fichiers et répertoires
• entrées de registre
• Services Windows
• dépendances d'exécution
• variables d'environnement
• associations de fichiers
• permissions
• raccourcis et fichiers de configuration

L'environnement dans lequel l'application est déployée peut être tout aussi important que l'installateur. Une application qui est développée et testée sur le poste de travail d'un développeur peut se comporter différemment lorsqu'elle est exécutée avec des autorisations d'utilisateur standard, sur une image Windows d'entreprise propre ou sur un environnement Windows Server multi-utilisateur .

Création et configuration de package

Les équipes informatiques préparent ensuite l'application en utilisant la technologie d'emballage appropriée pour le logiciel et le modèle de déploiement donnés.

Dans le cas des applications Windows, cela pourrait signifier créer un package MSIX. Cela pourrait impliquer de laisser des logiciels existants utilisant Win32 sous leur forme d'installateur MSI ou EXE ou de convertir certaines applications en MSIX. Différentes approches de packaging peuvent fournir une identité au package tout en permettant au logiciel de maintenir des éléments de son modèle d'installation existant.

Ainsi, il n'existe pas de format d'emballage unique qui convienne à toutes les applications Windows. L'application, son environnement et ses besoins en gestion devraient dicter l'approche d'emballage.

Tests et déploiement

Les forfaits devraient être testé sur des systèmes propres qui répliquent l'environnement de production cible.

Le processus de test doit inclure l'installation, le premier lancement, les dépendances, les mises à jour, la fonctionnalité de l'application et le comportement de désinstallation. Les administrateurs doivent également vérifier que les autorisations et les configurations spécifiques à l'utilisateur sont gérées correctement, en particulier en cas de redirection de fichiers ou de registre qui peut se produire lors de l'emballage des applications.

Après validation, les packages peuvent ensuite être distribués via la plateforme de distribution de logiciels ou de gestion des points de terminaison préférée de l'organisation.

Maintenant, faisons un pas en arrière et clarifions une distinction subtile mais d'une importance cruciale :

Les applications sont empaquetées, puis déployées

La séparation de ces fonctions est importante car elle crée un point de transition naturel pour la publication d'applications.

Qu'est-ce que la publication d'applications Windows ?

Publication d'applications Windows sert à publier une application qui est installée sur une infrastructure Windows centralisée pour des utilisateurs autorisés via un réseau ou Internet.

L'application est exécutée sur un hôte Windows distant au lieu d'être exécutée sur le point de terminaison de chaque utilisateur. Dans ce cas, l'utilisateur a accès à l'application exécutée à distance via un client compatible, un raccourci ou un navigateur web.

Application installée sur le serveur → utilisateur ayant obtenu l'accès → application exécutée sur le serveur → interface de l'application livrée à l'utilisateur

Cette approche est différente, car au lieu d'installer et de maintenir l'application métier sur chaque point de terminaison, les administrateurs doivent la maintenir sur les serveurs qui hébergent la session de l'utilisateur. Ainsi, les utilisateurs peuvent accéder à une application qui semble s'intégrer parfaitement dans leur environnement de travail, bien qu'elle soit hébergée sur une infrastructure centralisée.

Windows Application Packaging vs Publication d'Application : Quelles sont les différences ?

La distinction la plus simple est :

L'emballage des applications détermine comment le logiciel est préparé pour l'installation et la gestion. La publication des applications détermine comment les utilisateurs accèdent au logiciel s'exécutant sur une infrastructure centralisée.

Les technologies fonctionnent donc à différentes étapes de la livraison des applications.

Question	Emballage d'application Windows	Publication d'application
Objectif principal	Préparer le logiciel pour une installation et une maintenance répétables	Donner aux utilisateurs un accès aux applications hébergées de manière centralisée
Principale question informatique	Comment devrions-nous installer et gérer cette application ?	Comment les utilisateurs doivent-ils accéder à cette application et l'exécuter ?
Où l'application s'exécute-t-elle ?	Sur quel que soit le système qui reçoit l'application	Sur l'hôte de publication ou de session
Installation locale sur le point de terminaison de l'utilisateur ?	Généralement requis pour le déploiement des points de terminaison	L'installation complète de l'application n'est généralement pas requise
Mises à jour	Doit atteindre les objectifs de déploiement applicables	Peut être appliqué de manière centralisée aux hôtes de publication
Exigences de point de terminaison	L'endpoint doit prendre en charge l'application exécutée localement.	L'endpoint a principalement besoin d'une méthode d'accès compatible.
Portée typique	Gestion du cycle de vie des logiciels et des points de terminaison/serveurs	Livraison d'application centralisée
Cas d'utilisation courants	PCs gérés, logiciels standardisés, déploiements contrôlés	Utilisateurs distants, BYOD, applications héritées et accès centralisé aux applications

Une qualification : l'emballage des applications ne dicte pas où ledit logiciel est utilisé.

MSIX, MSI ou toute autre forme de package peut être déployé sur un poste de travail, un ordinateur portable, une machine virtuelle ou un serveur. L'emballage détermine comment le logiciel est installé et entretenu. Le déploiement cible détermine donc où l'application est installée.

La publication d'applications introduit une autre considération architecturale. Les processus d'application s'exécutent sur une infrastructure centralisée tandis que son interface est livrée sur des points de terminaison distants pour les utilisateurs autorisés.

Dans quel cas pourriez-vous utiliser l'emballage et la publication d'applications ensemble ?

Oui. Ils abordent différents points dans le cycle de livraison des applications et peuvent être utilisés indépendamment ou en combinaison.

Considérez une organisation qui dispose d'une application Windows de ligne de métier. Si elle doit être exécutée localement, elle peut être empaquetée et déployée sur chaque point de terminaison géré :

Package → déployer sur les points de terminaison → l'application s'exécute localement

Si l'organisation a besoin de centraliser, cela pourrait être empaqueté ou installé sur les hôtes de session pertinents et ensuite être publié :

Package ou installer → déployer sur des hôtes centralisés → publier → l'application s'exécute de manière centralisée

Dans ce cas, l'emballage des applications n'est pas nécessairement abandonné. Il est simplement appliqué à des hôtes centralisés au lieu de chaque appareil utilisateur, ce qui peut simplifier le maintien de la cohérence de l'application sur plusieurs serveurs de publication.

L'emballage d'application et la publication d'application ne sont pas mutuellement exclusifs : l'emballage standardise l'installation et la maintenance de l'application, tandis que la publication dicte sa méthode d'accès. En fonction des besoins de l'application, l'informatique peut utiliser une méthode, l'autre ou les deux en combinaison.

Dans quel cas il serait préférable d'utiliser l'emballage d'application Windows ?

L'emballage d'application Microsoft Windows est le plus approprié lorsque l'exécution locale est bénéfique, et que l'informatique peut gérer efficacement les appareils sur lesquels l'application est hébergée. Dans de tels cas, cela permet de standardiser l'installation et la maintenance tout en laissant le lieu d'exécution de l'application aux utilisateurs.

Les utilisateurs ont besoin d'un accès hors ligne

Les applications installées localement peuvent fonctionner efficacement, même si les utilisateurs ne peuvent pas accéder aux ressources centrales, ce qui est souvent le cas pour les employés mobiles, les travailleurs sur le terrain et d'autres travailleurs nomades.

L'emballage aide les organisations informatiques à garantir que cette approche est utilisée de manière cohérente en standardisant l'installation, la configuration et les mises à jour sur les points de terminaison gérés.

Les applications dépendent du matériel local ou du traitement

Certaines applications fonctionnent de manière plus efficace lorsqu'elles sont exécutées localement car elles dépendent intrinsèquement des ressources du point de terminaison ou y sont intégrées.

Le déploiement local évite l'introduction d'une session distante entre l'application et les ressources, et l'emballage fournit une méthode répétable pour installer et configurer l'application sur des points de terminaison capables de prendre en charge l'exécution locale.

Les points de terminaison sont standardisés et gérés de manière centralisée

L'emballage a également du sens dans la situation où une organisation dispose déjà d'un ensemble contrôlé d'appareils Windows et d'une plateforme de gestion des points de terminaison pour les gérer. Si l'environnement contient principalement des appareils et des systèmes d'exploitation similaires au même niveau de configuration, le déploiement et la gestion des applications locales peuvent ne présenter aucune difficulté significative.

Les packages offrent une approche organisée de la gestion des applications, ce qui facilite la tâche d'installation et de maintenance de l'application sur les appareils des utilisateurs finaux. Dans ce scénario, l'introduction d'une exécution centrale peut ne pas être nécessaire et ajouter une couche de complexité supplémentaire, à moins qu'il n'y ait un besoin commercial réel pour une telle mesure.

Par conséquent, la question clé n'est pas de savoir si l'application peut être empaquetée, mais si elle est viable à installer, mettre à jour et gérer sur chaque appareil cible en tenant compte de l'environnement et des exigences spécifiques.

Quand la publication d'applications a-t-elle plus de sens ?

La publication d'applications devient plus souhaitable lorsque l'installation locale entraîne des complexités opérationnelles ou de compatibilité excessives.

Plusieurs situations typiques méritent d'être prises en considération.

Utilisateurs distants et distribués

Les travailleurs à distance, le personnel des bureaux de succursales et les sous-traitants ne travaillent pas toujours à partir d'emplacements ou de dispositifs bien gérés comme des PC d'entreprise.

La publication d'applications préserve l'application Windows sur des serveurs centraux tout en permettant remote access par des utilisateurs autorisés, soulageant ainsi les administrateurs du fardeau de reproduire l'environnement d'application sur chaque appareil distant.

BYOD et environnements de points de terminaison mixtes

Une application Windows ne s'exécutera pas nécessairement sur tous les types d'appareils qu'une organisation particulière utilise.

La publication d'applications découple l'environnement d'exécution de l'utilisateur final. En utilisant une telle méthode, un individu peut accéder à une application Windows hébergée de manière centralisée via un navigateur ou un client approuvé sur sa machine, qui autrement ne pourrait pas exécuter l'application.

Cette stratégie est idéale pour les environnements bring-your-own-device (BYOD) et d'autres environnements où il existe plusieurs systèmes d'exploitation pour les points de terminaison.

Applications Windows héritées

Applications héritées peut compliquer les efforts de déploiement en s'appuyant sur des dépendances du système d'exploitation, des composants vieillissants et des contraintes de configuration difficiles.

Centraliser l'application peut aider à réduire les environnements dans lesquels l'informatique doit faire fonctionner le logiciel. Cela ne résoudra pas nécessairement les problèmes de compatibilité des applications, mais cela peut limiter ces problèmes à des hôtes Windows contrôlés, au lieu d'une collection dispersée de points de terminaison.

Cela peut simplifier la standardisation autour de l'accès aux applications héritées alors qu'une organisation travaille vers un plan de modernisation à long terme.

Applications nécessitant des mises à jour fréquentes

Des changements fréquents dans une application rendent son déploiement local plus difficile, surtout lorsque le nombre de points de terminaison augmente.

Avec la publication d'applications, les administrateurs mettent à jour l'application dans les hôtes centraux concernés. Les utilisateurs accèdent ensuite à l'application mise à jour sans avoir besoin de mettre à jour le logiciel sur tous les points de terminaison.

Le processus est particulièrement avantageux lorsque de nombreux utilisateurs dépendent de la même application mais n'ont pas à l'utiliser localement.

Comment les équipes informatiques devraient-elles choisir entre l'emballage et la publication ?

Les équipes informatiques devraient se concentrer sur les exigences opérationnelles de l'application plutôt que sur le choix de la technologie.

Si l'installation locale est facile à maintenir, vos points de terminaison sont étroitement contrôlés et les utilisateurs ont besoin de capacités hors ligne ou dépendantes du matériel, le déploiement d'endpoint packagé a le plus de sens. Si vos utilisateurs sont répartis, vos points de terminaison sont hétérogènes, l'installation locale est difficile ou l'application est plus facile à maintenir à jour de manière centralisée, la publication d'applications peut réduire la charge de gestion des points de terminaison.

De nombreuses entreprises auront besoin des deux modèles. Vos utilisateurs de bureau gérés pourraient obtenir des applications déployées localement, mais les sous-traitants, les télétravailleurs ou ceux utilisant des appareils non gérés pourraient obtenir un accès publié de manière centralisée à des logiciels professionnels spécifiques.

Le choix devient beaucoup plus clair si l'informatique découple trois questions.

1. Comment l'application doit-elle être empaquetée et maintenue ?
2. Où l'application doit-elle être déployée et exécutée ?
3. Comment les utilisateurs devraient-ils y accéder ?

Regarder l'emballage, le déploiement et l'accès comme des décisions séparées empêche de comparer deux technologies fondamentalement différentes comme si elles étaient la même solution.

Comment TSplus Remote Access peut-il être une solution ?

Les organisations qui souhaitent une livraison centralisée des applications Windows sans déployer l'application complète sur chaque point de terminaison peuvent utiliser TSplus Remote Access pour publier des applications Windows sélectionnées ou fournir des bureaux à distance complets à partir d'une infrastructure Windows centralisée.

Les administrateurs peuvent attribuer des applications à des utilisateurs ou groupes spécifiques et fournir un accès via des clients distants pris en charge ou des connexions HTML5 basées sur un navigateur. Cela rend la publication d'applications une option pour les organisations soutenant des utilisateurs distants, des environnements BYOD ou des applications Windows qui sont plus faciles à maintenir de manière centralisée.

Conclusion

L'emballage d'application Windows fournit un moyen répétable d'installer, de configurer et de maintenir des logiciels, tandis que la publication d'application donne aux utilisateurs accès à des applications s'exécutant sur une infrastructure centralisée. Aucune des deux approches ne remplace intrinsèquement l'autre, et les deux peuvent faire partie de la même stratégie de livraison d'application.

Le bon modèle dépend des exigences de l'application, de la gestion des points de terminaison et des besoins d'accès des utilisateurs. En considérant l'emballage, le lieu de déploiement et l'accès séparément, les équipes informatiques peuvent décider si une application doit fonctionner localement, de manière centralisée ou par une combinaison des deux modèles.