The Application Packager

une fois de plus examiné de près.

Exigence générale de qualité du point de vue de l'emballage de l'application

La mise en place d'applications requiert un mélange unique de compétences qui dépassent les limites organisationnelles de la plupart des départements informatiques.

Introduction

L'emballage des logiciels est souvent sous-estimé ou considéré comme une "activité secondaire". En raison de l'estimation incorrecte ...

  • dans la gestion
  • entre les employés de l'informatique
  • des fournisseurs aux clients
  • de la part des décideurs
.. sur le déploiement d'applications dans l'entreprise, des difficultés similaires se présentent souvent.

  • La complexité de l'emballage des applications est sous-estimée.
  • Le conditionnement des logiciels s'effectue à différents endroits de l'entreprise.
  • Les connaissances doivent donc être constituées de manière redondante en divers endroits et entretenues.
  • Taux d'erreur élevé dû au manque de connaissances.
  • Le processus global souffre d'une qualité médiocre ou insuffisante.
  • Le service "packaging / application provisioning" perd de plus en plus la confiance et l'acceptation au sein de l'entreprise.
La vérité est que presque plus personne ne sait comment classer correctement un packager de logiciels. Les spécialistes du matériel et des réseaux les considèrent comme des développeurs d'applications. Les développeurs d'applications les voient comme un support d'infrastructure. Le support d'infrastructure les voit comme un sous-ensemble bizarre. L'InfoSec ne perçoit les software packagers que lorsqu'ils demandent des exceptions de pare-feu et des exclusions de scan de malware. Pour beaucoup, le packaging logiciel n'est qu'un terme vague et non un titre de poste. Voici quelques exemples :

  • Packager SCCM
  • Spécialiste de l'infrastructure Service à la clientèle
  • Architecte de solutions TIC Plate-forme d'applications
  • Spécialiste système (MS Windows Client professionnel)
  • Ingénieur système (Intégration système)
  • Ingénieur système client
  • ou simple : Administrateur système

Classification selon ITIL

Si le rôle de l'empaqueteur de logiciels devait être classé selon ITIL, les employés chargés de l'empaquetage seraient subordonnés au secteur du développement des applications ou à un secteur lié au développement. Selon ITIL, la gestion des applications serait responsable de la création des paquets logiciels. Cette hypothèse repose principalement sur le fait que des connaissances en matière de développement d'applications sont souvent nécessaires pour développer une routine d'installation. La gestion des versions est responsable des tests et de la distribution des versions. La gestion des changements, quant à elle, est responsable de la surveillance et du contrôle.

Souvent, en raison du profil de spécialiste "software packager", l'activité de conditionnement des logiciels est placée dans un domaine distinct. Ce domaine doit être à la fois orienté système et orienté application. Dans la pratique, l'activité de production de paquets se situe presque essentiellement dans le domaine de la gestion des versions (RM). Cela est dû au fait que, dans l'usage normal, une unité de version est assimilée à un paquet. Puisque le RM est responsable de la création et du test des unités de version (et de la version), on peut justifier le fait qu'un packager peut / devrait être un employé du RM. En fin de compte, cependant, ITIL ne donne que des indices à ce stade et aucune spécification !

Assurance de la qualité

L'empaqueteur de logiciels est exclusivement responsable de la fonctionnalité technique du paquet. Il doit garantir, par des mécanismes appropriés, que le paquet répond aux exigences définies par le client. L'intégrateur de logiciels vérifie le progiciel sur un système de référence approprié, aussi proche que possible de la production et nécessaire à la mise en œuvre des spécifications et de l'opérabilité technique.

Responsabilité opérationnelle

L'empaqueteur de logiciels est exclusivement responsable de la création et du test des paquets correspondants. Tout ce qui concerne l'exploitation directe ou indirecte d'une application ne fait pas partie de sa responsabilité. Dans le cas du support, il représente un niveau de support accru (2ème ou 3ème niveau) du support de l'application.

Responsabilité de l'application

Chaque application utilisée a (idéalement) un propriétaire d'application (personne / groupe ou service). Un propriétaire d'application / propriétaire de produit est le premier point de contact pour toutes les questions relatives à l'application en usage productif. Il ou elle décide de la configuration de l'application (souvent en coopération avec d'autres départements informatiques ou unités commerciales). En outre, le propriétaire de l'application est souvent impliqué dans le processus d'achat, dans lequel il évalue (en coopération avec les départements) les fonctionnalités demandées et fait des recommandations de produits dans le cadre de l'achat.

En collaboration avec l'empaqueteur, le gestionnaire d'application vérifie l'applicabilité de l'application et la mise en œuvre de ses spécifications. Par le biais de l'acceptation (qui doit avoir lieu de manière appropriée et archivable), le propriétaire de l'application assume la responsabilité opérationnelle de son application.

Si l'application en production relève de la responsabilité du propriétaire de l'application, la routine d'installation (le paquet) doit rester sous la responsabilité de l'empaqueteur. À ce stade, il convient de noter que le paquet contenant l'application est en soi également une application.

Un packager de logiciels et un gestionnaire d'applications réunis

Bien que cela ne soit pas conseillé, dans certaines circonstances, il n'y a pas d'autre option que de combiner les rôles de propriétaire d'application et d'empaqueteur. Dans ce cas, l'empaqueteur de logiciels assume les fonctions et les responsabilités du propriétaire de l'application. Le risque de cette constellation réside dans les deux profils de spécialistes différents (propriétaire de l'application / empaqueteur de logiciels). Le conditionnement d'un paquet exige une connaissance approfondie à la fois de l'ingénierie des systèmes et des technologies d'automatisation. Si l'on suit le principe de "se concentrer sur l'activité principale", l'emballage supplémentaire des logiciels ou (à l'inverse) la responsabilité des applications est une déviation de l'activité principale. La conséquence de cette déviation est que soit deux profils spécialisés doivent être vécus (au sens de maîtrisés), soit l'activité principale est altérée par l'autre activité respective.

Conditionnement des applications par des prestataires de services externes

Si une entreprise ne dispose pas de ressources propres suffisantes, il est judicieux de mettre en œuvre le packaging logiciel avec l'aide d'un support externe. En se spécialisant dans le domaine de l'emballage de logiciels, les prestataires de services peuvent proposer des consultants / emballeurs de logiciels qui sont en mesure de remplir et de mettre en œuvre de manière professionnelle un profil de spécialiste "emballeur de logiciels". Il est également intéressant d'envisager que de tels spécialistes accompagnent l'emballage et constituent ainsi leurs propres ressources qualifiées. Du point de vue du fournisseur de services, un packager externe ne devrait jamais être responsable du fonctionnement d'une application à ce stade.

Un emballeur d'applications doit-il connaître le système de distribution des logiciels ?

Un emballeur de logiciels se définit principalement par d'autres compétences. Les exigences générales d'un emballeur de logiciels sont discutées plus en détail ci-dessous. Il y a plusieurs années, le terme "packager SCCM" a été introduit, ce qui a entraîné la nécessité de vivre (au sens de maîtriser) deux profils de spécialistes.

Conditions

Technologie du système

Une chose avant tout fait un bon empaqueteur de logiciels : Le conditionneur de logiciels doit avoir son client sous contrôle ! En particulier lors du conditionnement à l'aide de l'analyse delta, il est élémentaire et indispensable de nettoyer le script des entrées qui ont été enregistrées mais qui n'ont pas leur place dans le script après avoir créé avec succès l'analyse delta. Dans certaines circonstances, ces entrées peuvent causer des dommages irréparables aux systèmes cibles correspondants lors d'un déploiement de ce paquet. Dans ce cas, il faudrait réinstaller ces systèmes.

En premier lieu, un bon concepteur de progiciels doit maîtriser les systèmes d'exploitation pour lesquels il crée des progiciels dans le cadre de ses activités. Dans le second cas, il est certainement conseillé de s'occuper d'autres systèmes d'exploitation ou d'autres versions de systèmes d'exploitation, car le prochain déploiement/changement ne manquera pas d'arriver. Dans ce contexte, la maîtrise est définie comme suit:

  • Registry
    Le registre du système Windows ne devrait pas être un concept étranger. Un bon concepteur de logiciels doit connaître les valeurs par défaut de HKLM et HKCU. Pour une analyse delta, cette capacité est d'une importance élémentaire.
  • Services Windows
    Un packager logiciel doit être capable de comprendre les services Windows et de manipuler/modifier ces services dans son script si nécessaire. La connaissance de WMI est extrêmement utile. Avec WMI, il est par exemple possible d'interroger l'état du service installé après une installation et de réagir à cette information dans le script si nécessaire.
  • Gestion des droits et des utilisateurs NTFS
    En particulier dans l'analyse des erreurs, il est nécessaire de détecter les erreurs dues à un manque d'autorisation (système d'exploitation).
  • Connaissance du DOS
    Tout concepteur de logiciels devrait au moins être capable de maîtriser les commandes DOS de base. Malgré tous les moyens, il ne reste parfois que la ligne de commande comme dernier recours.
  • Langages de script
    Les langages de script sont souhaitables mais ne constituent pas une exigence de base (du moins dans le cadre d'un conditionnement normal). Lorsqu'un packager logiciel est capable d'utiliser VBS, JS, KIX, AUTOIT, etc., cela ouvre des possibilités techniques totalement nouvelles. Ces possibilités peuvent ensuite être utilisées pour surmonter des problèmes qui étaient auparavant considérés comme insolubles. "C'est impossible, ça n'existe pas !" Si une fonction n'est pas incluse de manière native dans , cette fonctionnalité peut être mappée via un langage de script (le plus souvent).
  • Protocoles de réseau (TCP/IP)
    "Des connaissances de base saines" dans le domaine de "l'internetworking" devraient également être disponibles. Un emballeur de logiciels doit être capable soit d'analyser et de qualifier les erreurs, soit de les réparer lui-même. Ces compétences comprennent également des connaissances dans le domaine du "dépannage IP" de base.
  • Compréhension de base des applications en général
    Toutes les applications sont similaires dans leur structure de base. Il y a généralement des éléments de menu où (et par lesquels) l'application peut être configurée. La plupart des applications écrivent leurs valeurs dans le registre. Grâce à ces deux informations, un spécialiste de l'empaquetage de logiciels est en mesure d'examiner une application du point de vue de l'empaquetage et d'aborder l'empaquetage approprié (les technologies d'installation telles que MSI, etc. seront abordées plus tard !)
  • Compréhension de base des réseaux client-serveur et des systèmes d'exploitation de réseau.
    Au plus tard lorsqu'une application doit être empaquetée pour un serveur (ou un serveur terminal), l'empaqueteur de logiciels doit connaître les bases du système d'exploitation du serveur correspondant.

Technologies d'installation

Fondamentalement, les types de technologies d'installation suivants peuvent être distingués:

  • MSI
    La technologie Microsoft Installer est en train de devenir la norme "de facto" en matière d'installation de logiciels. Un paquet MSI fournit une routine d'installation transparente avec de solides mécanismes d'assurance qualité. Les paquets MSI simplifient la réparation ou la désinstallation des applications. De nombreux produits contrôlent même la migration des applications vers une nouvelle version de manière totalement automatique. Un paquet MSI ne doit pas (meilleure pratique) être reconditionné en utilisant une analyse delta. Les interrelations système-technique d'une installation MSI sont très complexes et les mécanismes complets d'assurance qualité de la technologie Microsoft Installer peuvent être exploités.
  • Setup.exe (Configuration Legacy / Installation paramétrique)
    En règle générale, un tel Setup.exe (et cela ne concerne pas les installations qui appellent une installation MSI via un Setup.exe !) signifie qu'une analyse delta doit être créée pour ce paquet. Si nécessaire, ce Setup.exe peut également être paramétré. Les routines d'installation d'InstallShield offrent notamment la fonction de création d'un fichier de réponse pour la configuration de l'application, qui peut à son tour être utilisé dans le contexte d'une distribution pour la configuration automatique.

    MAIS:
    Avant d'utiliser une telle procédure, il faut d'abord répondre à la question de savoir comment le paquet doit être traité dans l'ensemble de la chaîne de processus.

Flexibilité

La flexibilité est une nécessité absolue, en particulier dans l'emballage des applications ! Il n'y a guère que dans le domaine de l'emballage des applications que l'on est confronté plus rapidement et plus régulièrement à de nouveaux défis. La routine et le conditionnement des logiciels ne vont ensemble que dans une mesure limitée. Fondamentalement, chaque exigence de conditionnement peut ou doit être traitée comme un projet distinct. Chaque projet comporte des risques et des points d'achoppement. En outre, chaque projet exige de la flexibilité pour s'adapter rapidement aux nouvelles situations et aux changements.

Compétences

Cette section énumère les domaines de compétence et les aptitudes/connaissances qu'un emballeur de logiciels doit posséder. Il est incontestable que ces informations ne constituent pas un must pour chaque employé, mais seulement une recommandation quant aux domaines abordés dans l'emballage des logiciels. Ne sont énumérés ici que les domaines, et non la profondeur requise dans chaque domaine. Cette évaluation approfondie doit être effectuée séparément, en fonction des besoins de l'entreprise concernée. Sur la base de ces informations, il est possible d'élaborer des options de soutien / mesures de soutien ciblées pour les employés qui se situent dans le champ de connaissances d'un concepteur de logiciels.

(Re)Conditionnement

  • Manipulation de la technologie Windows Installer (MSI, MST, MSP, MSM)
  • Traitement de la technologie Snapshot
  • Manipulation d'outils d'analyse (SysInternals)
  • Manipulation de la virtualisation (VMware, Hyper-V)
  • Manipulation d'outils de packaging (AdminStudio, Ivanti, ZenWorks, etc.)
  • Autres langages de script et de programmation:
    • Dos Batch
    • Visual Basic Script
    • Power-Shell
    • AutoIT

Client de systèmes d'exploitation

Windows 8, 10 Administration, installation et configuration

Serveur de systèmes d'exploitation

  • Windows Server, installation et configuration
  • Gestion des utilisateurs de domaine Windows
  • Services de terminal Windows
  • Administration d'Active Directory (ressources)

Client d'applications

  • MS Office
  • MS Outlook
  • IBM Notes
  • MS Edge, Firefox, Google Chrome
  • Adobe Acrobat (Reader et produit complet)
  • Java Runtime Environment (+JDK)
  • .NET (Runtimes), VC++ Runtimes
  • Plug-Ins
  • MS Hot fixes et Service packs

Serveur d'applications

  • MS SQL Server
  • MS Internet Information Server
  • Services de mise à jour Windows (WSUS)
  • Correctifs MS Hot et Service Packs
  • Administration de Citrix Presentation Server
  • Gestion des applications Citrix Presentation Server
  • Kit de développement logiciel (SDK) Citrix Presentation Server

Technologie Microsoft

  • Registre Windows, système de fichiers, ACL, UAC
  • Technologie MSI
  • WMI / WSH / ASDI
  • Installation du pilote, configuration (WDK) (également certification)
  • Kit (s) de ressources
  • Services et processus

TCP/IP

  • Configuration TCP/IP sur le client
  • Dépannage TCP/IP
  • Connaissance de base du DHCP
  • Connaissance de base du DNS
  • Détection et résolution des conflits d'adresses IP sur le client

Présentation

  • Structure et conception d'une présentation
  • Préparation d'une présentation
  • Réaliser une présentation

Modèles d'approche de projet

  • Configuration du projet
  • Culture de la rencontre
  • Création de rapports
  • Escalade
  • Gestion du temps
  • Travail prioritaire
  • Rapports
  • Création de documentation

Compréhension des processus

  • Compréhension des rôles
  • Connaissances de base ITIL (le cas échéant)
  • Processus d'amélioration continue

Compétences sociales

  • Communication
  • Travail en équipe
  • Capacité critique
  • Initiative personnelle
  • Créativité
  • Anglais
  • Compréhension du service
  • Action de résolution de problèmes
  • Acquisition indépendante de connaissances
  • Connaissance de la terminologie spécialisée