|
<< Click to Display Table of Contents >> RayPack > 7.3 u6 > User Guide > Appendix I: How to Set Up Your Packaging Environment Prerequisite Hardware |
The process steps of a common packaging project require at least a packaging machine running the application framework. Install the RayPack framework here. The data store for media management might also reside here. If the data store is placed on a shared network resource, make sure that it is accessible from the packaging machine.
Make sure the test and capture machines (see below) are as well within reach of the packaging machine. It is easier to transfer package material directly from one machine to another than to depend on crutches such as USB sticks or the like.
A test machine is used to run installations and uninstallations during the packaging preparation and quality assurance. The test machine should be configured to be as similar as possible to the productive environment the packed software is designed for. If there are several target scenarios, it is recommended to test the package on all of them. Nowadays test machines are usually virtual machines, equipped with predefined sets of reusable images and status snapshots.
Testing includes installing the built package, checking for basic functionality, and also checking the system state after uninstallation for unwanted relicts. A well designed package does not leave any undesired footprints once its uninstalled.
If there are intentions to use capturing functionalities during the packaging process, another machine type is needed. This one should be a blank installation of the target operating system, extended with the required set of prerequisites (such as runtime environments) for the installation of the application that is to be packaged.
Based on system snapshots before and after installations, RayPack's PackRecorder calculates the delta between those two states. Therefore the differences have to be exact towards the recorded differences between the system states before and after the installation that is to be observed. If the capturing machine has other software installed, there might be issues and conflicts in resource usage, since every application installation brings along a varying set of resources that are integrated into the system of the machine.
Imagine a Sample.dll, which exists in the initial snapshot taken from the system, because it was installed along with an application that is not part of the prerequisite set for the application that is about to be packaged. Now the application that is about to be captured is installed on the same system, requiring the Sample.dll. If it is already available, the installation will not change the system state in this point; the second snapshot taken after the installation will include the .dll as well. Comparing the initial and post-installation snapshots will not reveal any change in the system state regarding this .dll file. Therefore, the delta file of differences will not include this specific .dll. If this missing resource is not detected, the following packaging process might very well lead to an erroneous result. If the .dll is part of a required prerequisite, there is no major issue, since the package is intended to be placed into such a system.
Think of access attempts to the registry, to .dlls and directories as "background noise" caused by applications running on a machine. The capture machine should run with the little noise the possible, to make it easier to actually "listen" to the applications installation activities. Capturing results can be focused to specific system parts by exclusion lists, but the cleaner the capture machine is, the less need for manual correction and manipulation is required as capturing pre- and postwork.
By the way, using the term "machine" does not mean that there is a need for several physical machines for repackaging. Modern packaging factories are mostly virtualized, since it is way more handy to work with several virtual machines, instead of maintaining a broad variety of actual hardware machines.