As already mentioned before, packaging is way more than simply manipulating some package properties. Before starting to go for actual package designing, make sure that the target installation scenario is well defined, the basic material is flawless and complete, and there exists a clear conception of quality criteria the package has to fulfill.
Wrapped in the standardized Enterprise Application Lifecycle Management process, the steps for the realization of a package request might very well come close to a workflow similar to this one:
1.RayFlow: Incoming package order from the customer
2.RayEval: Evaluation of packaging requirements, creation of installation description
3.RayPack: Packaging procedures (tailoring a transform, repackaging legacy formats, designing complex packaging solutions, package validation)
4.RayQC: Quality control tasks regarding the delivered target package
5.RayFlow: Package acceptance by the customer
6.RayManageSoft: Deploying the package according to customer standards
Since packaging is only one part of the EAL process (=Enterprise Application Lifecycle), the actual full cycle requires prior steps, such as recording inventory to be able to gather target machine requirements, licensing status, and the like.
Depending on your individual packaging environment, the tools you utilize to master process steps may vary. The illustration above shows a typical setup for frameworks which operate on Raynet standard applications and services, such as RayFlow, RayEval, RayQC, or RayManageSoft. However, RayPack is a framework you can implement in combination with any kind of third-party tool.
Experienced packagers base their work on a core set of standard procedures, and adjust them towards the specific requirements of each individual packaging job and project environment: No matter which format or operating system is the target - no package should go out to the productive environment without decent quality checks. However, which tests have to be applied may vary. The same is to be said about package deployment. It is a usual enterprise requirement to create a package that is installed silently, meaning without the need for user interaction during installation. Beyond that common ground, the market leading deployment systems do not share a common standard for deployment management. Depending on the operative deployment method, each custom software package has to be adjusted to be able to flow smoothly through the individual deployment process.
Naming Conventions
In order to organize package resources, it is highly recommended to apply a naming convention for projects and packages. There are basic properties which are available for each package project. Using them to organize the storage hierarchy within the data store provides quick orientation and package identification at a glance. Sticking to a structured convention also enables automated task execution and rule based data extraction.
Typical elements of a package naming conventions are:
•Local package id
If using workflow management tools, such as RayFlow, it is common to define a project specific, locally unique job id. In order to quickly identify the package that belongs to a certain RayFlow job, it is convenient to use the id within the package project name.
•Vendor name, software name, software version
The combination of these three properties definitely identifies the basic software. Make sure to use a standard version convention to reflect major, minor and patched versions.
•Package type
The target package type is decisive for many operational steps, therefore a type identifier within the project title provides essential information about the project without the need to open it's documentation or project file. Make sure to define a standard identifier system to use throughout all packaging projects.
•Source type
Add an identifier reflecting the source media type. Is it a native MSI file, as provided by the original vendor, an original legacy installation, an already wrapped or repackaged MSI.
Again, it is not necessary to apply a naming convention, but defining one will surely lead to benefits regarding the organization level of the packages and the level of automation that can be applied on the stored package media.