The Application Packager

once more closely examined.

General quality requirement from the point of view of software packaging

Application packaging requires a unique blend of skills that crosses the typical organizational boundaries of most IT departments.

Introduction

Application packaging is often underestimated or considered a "side activity". Due to the misestimation ...

  • in Management
  • between IT employees
  • from suppliers via customers
  • from decision makers
... about the deployment of applications in the enterprise, similar difficulties often arise:

  • Complexity of application packaging is underestimated.
  • Application packaging is carried out at various points in the company.
  • Knowledge must therefore be built up redundantly in various places and maintained.
  • High error rate due to lack of knowledge.
  • The overall process suffers due to poor or only sufficient quality.
  • The service "application packaging / application deployment" is becoming a buzzword in the enterprises.
The truth is that hardly anyone knows how to correctly classify a application packager anymore. Hardware and network people see them as app developers. App developers see them as infrastructure support. Infrastructure support sees them as a weird subset. InfoSec only perceives application packagers when they ask for firewall exceptions and malware scan exclusions. For many, application packaging is just a vague term and not a job title. A few examples:

  • SCCM-Packager
  • Infrastructure Specialist Client Service
  • ICT Solution Architect Application plattform
  • System Specialist (Professional MS Windows Client)
  • System Engineer (System Integration)
  • Client System Engineer
  • or simple: System Administrator

Classification according to ITIL

If the role of the software packager were to be classified according to ITIL, the packaging employees would be subordinate to the application development area or a development-related area. According to ITIL, Application Management would be responsible for creating software packages. This assumption is based primarily on the fact that application development knowledge is often required to develop an installation routine. Release Management is responsible for release testing and release distribution. Change management, in turn, is responsible for monitoring and control.

Often, due to the specialist profile "software packager", the activity of software packaging is placed in a separate area. This area must act both system-oriented and application-oriented. In practice the activity of the package production is settled almost predominantly in the range of the release management (RM). This is due to the fact that a release unit is equated with a package in normal usage. Since the RM is responsible for the creation and testing of the Release Units (and the Release), it can be justified by the fact that a packager can / should be an RM - employee. Ultimately, however, ITIL only gives hints at this point and no specifications!

Quality assurance

The software packager is exclusively responsible for the technical functionality of the package. He has to ensure the quality by suitable mechanisms that the package fulfills the requirements defined by the customer. The software packager checks the package on an appropriate reference system as close to production as possible and necessary for implementation of the specifications and technical operability.

Operational responsibility

The application packager is exclusively responsible for creating and testing the corresponding packages. All matters relating to the direct or indirect operation of an application are neither his responsibility nor his responsibility. In case of support, he represents an increased (2nd or 3rd level) support level of the application support.

Application responsibility

Each application in use has (ideally) an application owner (person / group or department). An application owner / product owner is the first point of contact for all matters relating to the application in productive use. He or she decides on the configuration of the application (often in cooperation with other IT departments or business units). In addition, the application owner is often involved in the procurement process, in which he or she evaluates the requested functionalities (in collaboration with the departments) and makes product recommendations as part of the procurement process.

Together with the packager, the application owner checks the application for executability and implementation of his specifications. Through the acceptance (which should take place in an appropriately archivable manner), the application owner assumes the operational responsibility for his application.

While the application in production is the responsibility of the application owner, the installation routine (the package) should nevertheless remain the responsibility of the packager. At this point it should be noted that the package containing the application is in itself also an application.

Application packager and application manager in one person

Although it is not advisable, under certain circumstances there may be no other option than to combine the roles of application owner and packager. In this case, the software packager assumes the duties and responsibilities of the application owner. The risk of this constellation lies in the two different specialist profiles (application owner / software packager). Packaging a package requires in-depth knowledge of both systems engineering and automation technologies. Should the premise of "concentrating on the core business" be followed, the additional packaging or (conversely) application responsibility is a deviation from the core business. The consequence of this deviation is that either two specialist profiles must be lived (in the sense of mastered) or the core business is impaired by the other activity in each case.

Application packaging by external service providers

If a company does not have sufficient resources of its own, it makes perfect sense to implement application packaging with the help of external support. By specializing in the area of application packaging, service providers can offer consultants / application packagers who are able to professionally fulfill and implement a specialist profile of "application packager". It is also worth considering having such specialists accompany the packaging and building up their own qualified resources in this way. From the service provider's point of view, an external packager must never be responsible for the operation of an application at this point.

Does an application packager need knowledge of the software distribution system?

An application packager is primarily defined by other skills. The general requirements of an application packager are discussed in more detail below. The term "SCCM packager" was introduced a few years ago, which meant that two specialist profiles had to be lived (in the sense of mastered).

Requirements

System technology

One thing above all makes a good application packager: He/she must have his/her client under control! Especially when packaging using delta analysis, it is elementary and indispensable to clean the script of entries that were recorded but do not belong in the script after the delta analysis has been successfully created. Under certain circumstances, these entries can cause irreparable damage to the corresponding target systems during a rollout of this package. In this case, these systems would have to be reinstalled.

In the first instance, a good application packager should have a command of the operating systems for which he creates software packages as part of his activities. In the second instance, it is certainly advisable to deal with other operating systems or operating system versions, as the next rollout / changeover is sure to come. Mastery in this context is defined as follows:

  • Registry
    The Windows System Registry must not be a foreign concept. A good application packager must be familiar with the default values in HKLM and HKCU. This ability is of elementary importance for a delta analysis.
  • Windows services
    An application packager must be able to understand Windows services and handle / modify these services in his script if necessary. Knowledge of WMI is extremely helpful. Using WMI, it is possible, for example, to query the status of the installed service after an installation and, if necessary, to react to this information in the script accordingly.
  • NTFS rights and user management
    Especially in error analysis, it is a necessity that errors are detected that are due to a lack of authorization (operating system).
  • DOS knowledge
    Every application packager should at least be able to master the basic DOS commands. Despite all means, now and then the command line is the last resort.
  • Scripting languages
    Scripting languages are desirable but not a basic requirement (at least in normal packaging). If an application packager is able to use VBS, JS, KIX, AUTOIT, etc., completely new technical possibilities open up to him. These possibilities can then be used to overcome problems that were previously considered unsolvable. "Can't be done, doesn't exist!" If a function is not natively contained in , this functionality can be mapped via a script language (mostly).
  • Network protocols (TCP/IP)
    A "healthy basic knowledge" in the area of "Internetworking" should also be available. An application packager should be able to either analyze and qualify errors or fix them himself. These skills also include knowledge in the area of basic "IP trouble shooting".
  • Basic understanding of applications in general
    All applications are similar in their basic structure. As a rule, there are menu items in which (and via which) the application can be configured. Most applications write their values to the registry. With these two insights, an application packager is able to look at an application from a packaging perspective and approach packaging accordingly.
  • Basic understanding of client server networks and network operating systems
    At the latest when an application is to be packaged for a server (or terminal server), the application packager should be familiar with the basic features of the corresponding server operating system.

Installation technologies

Basically, the following types of installation technologies can be distinguished:

  • MSI
    Microsoft Installer technology is becoming the "de facto" standard in software installation. An MSI package provides a transparent installation routine with strong QA mechanisms. MSI packages simplify an "application repair" or the uninstallation of an application. Many products even control application migration to a new release completely automatically. An MSI package should not (in the sense of may) be repackaged by means of a delta analysis. The system technical interrelationships of an MSI installation are very complex and the complete QA mechanisms of the Microsoft Installer technology can be leveraged.
  • Setup.exe (Legacy Setup / Parameterized installation)
    As a rule, such a Setup.exe (and this does not mean the installations that call an MSI installation via a Setup.exe!) means that a delta analysis must be created for this package. If necessary this Setup.exe can be called also parameterized. Especially InstallShield setup routines offer the function to generate a response file for the application configuration, which in turn can be used in the context of a distribution for (conditional) automatic configuration.

    But:
    Before such a process is used, the questions of how to handle the package in the entire process chain should first be answered.

Flexibility

Flexibility is an absolute must, especially in application packaging! Almost nowhere are you confronted with new challenges more quickly and regularly than in application packaging. Routine and application packaging only go together to a limited extent. Basically, each packaging requirement can or should be treated as a separate project. Each project has risks and stumbling blocks. Furthermore, every project requires flexibility to quickly adapt to new situations and changes.

Competencies

This section lists areas of competence and skills / knowledge that an application packager should possess. It is undisputed that this information does not represent a must for every employee, but is only a recommendation as to which areas are addressed in application packaging. Listed here are only the areas, not the depth required in each area. Such a depth assessment should be made separately to meet the needs of the particular company. On the basis of the information gained from this, targeted support options / support measures can be worked out for employees who are within the knowledge range of an application packager.

(Re)-packaging

  • Handling Windows Installer technology (MSI, MST, MSP, MSM)
  • Handling Snapshot technology
  • Handling packaging tools (AdminStudio, Ivanti, ZenWorks, etc.)
  • Handling of analysis tools (SysInternals)
  • Handling virtualization (VMware, Hyper-V)
  • Other scripting and programming languages:
    • Dos Batch
    • Visual Basic Script
    • Power-Shell
    • AutoIT

Operating systems client

Windows 8, 10 Administration, installation and configuration

Operating systems server

  • Windows Server, Installation and configuration
  • Windows Domain User Management
  • Windows Terminal Services
  • Active Directory Administration (Ressources)

Applikationen Client

  • MS Office
  • MS Outlook
  • IBM Notes
  • Internet Explorer (mit IEAK), MS Edge, Firefox, Google Chrome
  • Adobe Acrobat (Reader and full product)
  • Java Runtime Environment (+JDK)
  • .NET (Runtimes), VC++ Runtimes
  • Plug-Ins
  • MS Hot fixes und Service packs

Applicationen Server

  • MS SQL Server
  • MS Internet Information Server
  • Windows Update Services (WSUS)
  • MS Hot fixes and Service packs
  • Citrix Presentation Server Administration
  • Citrix Presentation Server Applikationshandling
  • Citrix Presentation Server SDK

Microsoft Technology

  • Windows Registry, file system, ACL, UAC
  • MSI Technology
  • WMI / WSH / ASDI
  • Driver installation, configuration (WDK) (also certification)
  • Ressource Kit(s)
  • Services and processes

TCP/IP

  • TCP/IP Configuration on the client
  • TCP/IP Troubleshooting
  • Basic knowledge DHCP
  • Basic knowledge DNS
  • Detection and resolution of IP address conflicts on the client

Presentation

  • Structure and design of a presentation
  • Preparation of a presentation
  • Conducting a presentation

Project approach models

  • Project setup
  • Meeting culture
  • Report creation
  • Escalation
  • Time management
  • Prioritized work
  • Reporting
  • Creation of documentation

Process understanding

  • Understanding of roles
  • ITIL Basic knowledge
  • Continuous improvement process

Social skills

  • Communication
  • Ability to work in a team
  • Critical faculties
  • Initiative
  • Creativity
  • English
  • Understanding of service
  • Problem solving oriented action
  • Independent acquisition of knowledge
  • Knowledge of technical terminology