The Application Packager

ancora una volta esaminato da vicino.

Requisiti generali di qualità dal punto di vista del packaging del software

Il packaging delle applicazioni richiede una miscela unica di competenze che attraversa i confini organizzativi tipici della maggior parte dei dipartimenti IT.

Introduzione

Il packaging delle applicazioni è spesso sottovalutato o considerato un'"attività secondaria". A causa dell'errata valutazione ...

  • nella gestione
  • tra i dipendenti IT
  • dai fornitori attraverso i clienti
  • dai responsabili delle decisioni
... sullo spiegamento di applicazioni nell'impresa, sorgono spesso difficoltà simili:

  • La complessità del packaging delle applicazioni è sottovalutata.
  • Il confezionamento delle applicazioni viene effettuato in vari punti dell'azienda.
  • La conoscenza deve quindi essere costruita e mantenuta in modo ridondante in luoghi diversi.
  • Alto tasso di errore dovuto alla mancanza di know-how.
  • L'intero processo soffre a causa di una qualità inadeguata o solo sufficiente.
  • Il servizio "application packaging / application provisioning" sta perdendo sempre più fiducia e accettazione in azienda.
La verità è che quasi nessuno sa più come classificare correttamente un packager di applicazioni. Quelli dell'hardware e del networking li vedono come sviluppatori di app. Gli sviluppatori di app li vedono come supporto all'infrastruttura. Infrastructure Support li vede come uno strano sottoinsieme. L'InfoSec percepisce i pacchettizzatori di applicazioni solo quando chiedono eccezioni firewall ed esclusioni di scansioni malware. Per molti, l'imballaggio delle applicazioni è solo un termine vago e non un titolo di lavoro. Alcuni esempi:

  • Impacchettatore SCCM
  • Specialista dell'infrastruttura Servizio clienti
  • Architetto di soluzioni ICT Application plattform
  • Specialista di sistema (Client MS Windows professionale)
  • Ingegnere di sistema (integrazione di sistema)
  • Ingegnere di sistema client
  • o semplice: Amministratore di sistema

Classificazione secondo ITIL

Se il ruolo del packager del software dovesse essere classificato secondo ITIL, gli impiegati del packaging sarebbero subordinati all'area di sviluppo delle applicazioni o a un'area legata allo sviluppo. Secondo ITIL, la gestione delle applicazioni sarebbe responsabile della creazione dei pacchetti software. Questa supposizione si basa principalmente sul fatto che la conoscenza dello sviluppo delle applicazioni è spesso necessaria per sviluppare una routine di installazione. Il Release Management è responsabile dei test di rilascio e della distribuzione del rilascio. Il Change Management, a sua volta, è responsabile del monitoraggio e del controllo.

Spesso, a causa del profilo specialistico "software packager", l'attività di packaging del software è posta in un'area separata. Quest'area deve agire sia orientata al sistema che all'applicazione. In pratica l'attività di produzione di pacchetti è stabilita quasi prevalentemente nell'ambito del release management (RM). Questo è dovuto al fatto che un'unità di rilascio è equiparata a un pacchetto nell'uso normale. Dato che il RM è responsabile della creazione e del test delle unità di rilascio (e del rilascio), può essere giustificato dal fatto che un packager può/deve essere un RM - dipendente. In definitiva, però, ITIL dà solo accenni a questo punto e nessuna specifica!

Garanzia di qualità

L'application packager è esclusivamente responsabile della funzionalità tecnica del pacchetto. Egli deve garantire la qualità attraverso meccanismi adeguati che il pacchetto soddisfi i requisiti definiti dal cliente. L'application packager controlla il pacchetto su un sistema di riferimento appropriato il più vicino possibile alla produzione e necessario per l'implementazione delle specifiche e l'operatività tecnica.

Responsabilità operativa

Il packager del software è esclusivamente responsabile della creazione e del test dei pacchetti corrispondenti. Tutte le questioni riguardanti il funzionamento diretto o indiretto di un'applicazione non fanno parte della sua responsabilità. Nel caso del supporto, rappresenta un livello di supporto aumentato (2° o 3° livello) del supporto dell'applicazione.

Responsabilità dell'applicazione

Ogni applicazione in uso ha (idealmente) un proprietario dell'applicazione (persona/gruppo o dipartimento). Un proprietario dell'applicazione / proprietario del prodotto è il primo punto di contatto per tutte le questioni relative all'applicazione in uso produttivo. Lui o lei decide la configurazione dell'applicazione (spesso in cooperazione con altri dipartimenti IT o unità aziendali). Inoltre, il proprietario dell'applicazione è spesso coinvolto nel processo di approvvigionamento, in cui valuta (in collaborazione con i dipartimenti) le funzionalità richieste e fa raccomandazioni sul prodotto nel quadro dell'approvvigionamento.

Insieme al packager, il gestore dell'applicazione controlla l'eseguibilità dell'applicazione e l'implementazione delle sue specifiche. Attraverso l'accettazione (che dovrebbe avvenire in un modo adeguatamente archiviabile), il proprietario dell'applicazione si assume la responsabilità operativa della sua applicazione.

Mentre l'applicazione in produzione è responsabilità del proprietario dell'applicazione, la routine di installazione (il pacchetto) dovrebbe comunque rimanere responsabilità del packager. A questo punto va notato che il pacchetto che contiene l'applicazione è di per sé anche un'applicazione.

Software packager e application manager riuniti in uno

Anche se non è consigliabile, in alcune circostanze potrebbe non esserci altra opzione che combinare i ruoli di proprietario dell'applicazione e packager. In questo caso, il packager del software assume i doveri e le responsabilità del proprietario dell'applicazione. Il rischio di questa costellazione sta nei due diversi profili specialistici (proprietario dell'applicazione / packager del software). Il confezionamento di un pacchetto richiede una conoscenza approfondita sia dell'ingegneria dei sistemi che delle tecnologie di automazione. Se si dovesse seguire la premessa di "concentrarsi sul core business", il packaging aggiuntivo del software o (al contrario) la responsabilità delle applicazioni è una deviazione dal core business. La conseguenza di questa deviazione è che o due profili specializzati devono essere vissuti (nel senso di padroneggiati) o il core business è compromesso dalla rispettiva altra attività.

Imballaggio delle applicazioni da parte di fornitori di servizi esterni

Se un'azienda non ha sufficienti risorse proprie, ha senso implementare il packaging del software con l'aiuto di un supporto esterno. Specializzandosi nell'area del packaging del software, i fornitori di servizi possono offrire consulenti/imballatori di software che sono in grado di soddisfare e implementare professionalmente un profilo specialistico "imballatore di software". Vale anche la pena di prendere in considerazione l'idea di far accompagnare l'imballaggio da questi specialisti e di costruire in questo modo le proprie risorse qualificate. Dal punto di vista del fornitore di servizi, un packager esterno non dovrebbe mai essere responsabile del funzionamento di un'applicazione a questo punto.

Un packager di applicazioni deve conoscere il sistema di distribuzione del software?

Un packager di software è definito principalmente da altre competenze. I requisiti generali di un packager di software sono discussi più in dettaglio qui sotto. Diversi anni fa, è stato introdotto il termine "SCCM packager", che significava che due profili specializzati dovevano essere vissuti (nel senso di padroneggiati).

Requisiti

Tecnologia di sistema

Una cosa su tutte fa un buon packager di software: Il software packager deve avere il suo cliente sotto controllo! Specialmente quando si confeziona usando l'analisi delta, è elementare e indispensabile pulire lo script dalle voci che sono state registrate ma che non appartengono allo script dopo aver creato con successo l'analisi delta. In certe circostanze, queste voci possono causare danni irreparabili ai corrispondenti sistemi di destinazione durante un rollout di questo pacchetto. In questo caso, questi sistemi dovrebbero essere reinstallati.

In primo luogo, un buon packager di software dovrebbe essere competente nei sistemi operativi per i quali sta creando pacchetti software come parte delle sue attività. Nel secondo caso, è certamente consigliabile trattare con altri sistemi operativi o versioni del sistema operativo, dato che il prossimo rollout/cambio arriverà sicuramente. La padronanza in questo contesto è definita come segue:

  • Registry
    Il registro di sistema di Windows non dovrebbe essere un concetto estraneo. Un buon packager di software deve avere familiarità con i valori predefiniti in HKLM e HKCU. Per un'analisi delta questa capacità è di elementare importanza.
  • Servizi di Windows
    Un packager di software deve essere in grado di capire i servizi di Windows e gestire/modificare questi servizi nel suo script, se necessario. La conoscenza di WMI è estremamente utile. Con WMI è per esempio possibile interrogare lo stato del servizio installato dopo un'installazione e reagire a questa informazione nello script se necessario.
  • Diritti NTFS e gestione degli utenti
    Specialmente nell'analisi degli errori è una necessità che vengano rilevati gli errori che sono dovuti a una mancanza di autorizzazione (sistema operativo).
  • Conoscenza del DOS
    Ogni produttore di software dovrebbe almeno essere in grado di padroneggiare i comandi di base del DOS. Nonostante tutti i mezzi, ogni tanto rimane solo la linea di comando come ultima risorsa.
  • Linguaggi di scripting
    I linguaggi di scripting sono auspicabili ma non un requisito fondamentale (almeno nella confezione normale). Quando un packager di software è in grado di usare VBS, JS, KIX, AUTOIT, ecc., apre possibilità tecniche completamente nuove. Queste possibilità possono poi essere utilizzate per superare problemi che prima erano considerati irrisolvibili. "Non si può fare, non esiste!" Se una funzione non è inclusa nativamente in , questa funzionalità può essere mappata tramite un linguaggio di scripting (per lo più).
  • Protocolli di rete (TCP/IP)
    "Una sana conoscenza di base" nell'area di "internetworking" dovrebbe anche essere disponibile. Un packager di software dovrebbe essere in grado di analizzare e qualificare gli errori o di correggerli lui stesso. Queste competenze includono anche la conoscenza nell'area della "risoluzione dei problemi IP" di base.
  • Comprensione di base delle applicazioni in generale
    Tutte le applicazioni sono simili nella loro struttura di base. Di solito ci sono voci di menu dove (e attraverso le quali) l'applicazione può essere configurata. La maggior parte delle applicazioni scrive i propri valori nel registro. Con queste due intuizioni, un packager di software è in grado di guardare un'applicazione dal punto di vista del packaging e avvicinarsi al packaging appropriato (le tecnologie di installazione come MSI ecc. saranno trattate più avanti!)
  • Comprensione di base delle reti client server e dei sistemi operativi di rete
    Al più tardi quando un'applicazione deve essere impacchettata per un server (o terminal server), il packager del software dovrebbe avere familiarità con le basi del sistema operativo del server corrispondente.

Tecnologie di installazione

Fondamentalmente, i seguenti tipi di tecnologie di installazione possono essere distinti:

  • MSI
    La tecnologia Microsoft Installer sta diventando lo standard "de facto" nell'installazione del software. Un pacchetto MSI è una routine di installazione trasparente con forti meccanismi di QA. I pacchetti MSI semplificano la riparazione o la disinstallazione delle applicazioni. Molti prodotti controllano persino la migrazione delle applicazioni a una nuova release in modo completamente automatico. Un pacchetto MSI non dovrebbe (nel senso di può) essere riconfezionato usando un'analisi delta. Le interrelazioni tecnico-sistemiche di un'installazione MSI sono molto complesse e i meccanismi completi di QA della tecnologia Microsoft Installer possono essere sfruttati.
  • Setup.exe (Installazione legacy Setup / Parametric Installazione)
    Di regola, un tale Setup.exe (e questo non significa le installazioni che chiamano un'installazione MSI tramite un Setup.exe!) significa che deve essere creata un'analisi delta per questo pacchetto. Se necessario, questo Setup.exe può anche essere chiamato parametrizzato. Specialmente le routine di setup di InstallShield offrono la funzione di creare un file di risposta per la configurazione dell'applicazione, che a sua volta può essere usato nel contesto di una distribuzione per la configurazione automatica.

    MA:
    Prima di utilizzare una procedura di questo tipo, si dovrebbe prima rispondere alle domande su come il pacchetto dovrebbe essere gestito nell'intera catena del processo.

Flessibilità

La flessibilità è un must assoluto, soprattutto nel packaging delle applicazioni! Quasi da nessuna parte ci si confronta con nuove sfide più rapidamente e regolarmente che nel packaging delle applicazioni. La routine e la confezione del software vanno insieme solo in misura limitata. Fondamentalmente, ogni requisito di imballaggio può o dovrebbe essere trattato come un progetto separato. Ogni progetto ha dei rischi e degli ostacoli. Inoltre, ogni progetto richiede flessibilità per adattarsi rapidamente a nuove situazioni e cambiamenti.

Competenze

Questa sezione elenca le aree di competenza e le abilità/conoscenze che un packager di software dovrebbe possedere. È indiscutibile che queste informazioni non rappresentano un must per ogni dipendente, ma sono solo una raccomandazione su quali aree sono affrontate nella confezione del software. Qui sono elencate solo le aree, non la profondità richiesta in ogni area. Tale valutazione approfondita dovrebbe essere fatta separatamente in base alle esigenze della particolare azienda. Sulla base delle informazioni ottenute da questo, possono essere elaborate opzioni di supporto mirate / misure di supporto per i dipendenti che si trovano nella gamma di conoscenze di un packager di software.

(Ri-)Imballaggio

  • Gestione della tecnologia Windows Installer (MSI, MST, MSP, MSM)
  • Gestione della tecnologia Snapshot
  • Gestione di strumenti di analisi (SysInternals)
  • Gestione della virtualizzazione (VMware, Hyper-V)
  • Manipolazione di strumenti di packaging (AdminStudio, Ivanti, ZenWorks, ecc.)
  • Altri linguaggi di scripting e programmazione:
    • Dos Batch
    • Visual Basic Script
    • Power-Shell
    • AutoIT

Client di sistemi operativi

Windows 8, 10 Amministrazione, installazione e configurazione

Server dei sistemi operativi

  • Windows Server, installazione e configurazione
  • Gestione degli utenti del dominio Windows
  • Servizi terminal di Windows
  • Amministrazione di Active Directory (risorse)

Client di applicazioni

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

Server delle applicazioni

  • MS SQL Server
  • MS Internet Information Server
  • Servizi di Windows Update (WSUS)
  • MS Hot fixes e Service packs
  • Amministrazione di Citrix Presentation Server
  • Gestione delle applicazioni Citrix Presentation Server
  • Citrix Presentation Server SDK

Tecnologia Microsoft

  • Registro di sistema di Windows, file system, ACL, UAC
  • Tecnologia MSI
  • WMI / WSH / ASDI
  • Installazione driver, configurazione (WDK) (anche certificazione)
  • Kit di risorse
  • Servizi e processi

TCP/IP

  • Configurazione TCP/IP sul client
  • Risoluzione dei problemi TCP/IP
  • Conoscenza di base del DHCP
  • Conoscenza di base del DNS
  • Rilevamento e risoluzione dei conflitti di indirizzi IP sul client

Presentazione

  • Struttura e design di una presentazione
  • Preparazione di una presentazione
  • Realizzazione di una presentazione

Modelli di approccio al progetto

  • Configurazione del progetto
  • Cultura dell'incontro
  • Creazione di report
  • Escalation
  • Gestione del tempo
  • Priorità al lavoro
  • Segnalazione
  • Creazione della documentazione

Comprensione del processo

  • Comprensione dei ruoli
  • Conoscenza di base ITIL (se applicabile)
  • Processo di miglioramento continuo

Abilità sociali

  • Comunicazione
  • Lavoro di squadra
  • Capacità critica
  • Iniziativa personale
  • Creatività
  • Inglese
  • Comprensione del servizio
  • Azione di risoluzione dei problemi
  • Acquisizione indipendente di conoscenze
  • Conoscenza della terminologia specialistica