Package design pattern
From ControlTier
Contents |
Intent
- Define an object that encapsulates the lifecycle of a software package.
- Abstract the parameters common to packages of different formats.
- Abstract the methods to controlling packages of different formats.
Problem
We want to create and install packages of various formats but these packages have varying degrees of capability and require thier own tool sets to produce them. Lacking a standard way of creating, distributing and installing packages undermines the goal of a generic deployment procedure.
Discussion
Depending on their architecture and platform, applications are released using a wide variety of formats. The components of a Java based applications may be deployed as .jar, .war, and .ear files, while platform software may be deployed as .rpm, .deb, and .pkg files. Windows based applications have their own range of deployable artifacts and installers: .dll, .exe, .setup, .zip. Indeed, many software components are distributed as they are, devoid of any formalized packaged delivery.
When one considers the common details and requirements for software packages they can be organized into different categories:
- parameters: these are key attributes that describe the package.
- lifecycle: these are the set of procedures needed to create and manage the package.
- dependencies: these are the requirements needed both to build the package and the assumptions about the dependencies that will be met when the package is installed.
Due to this diversity of software delivery, one is often faced with using a myriad of tools and a recipe of procedures to prepare, deliver and install software components. This requires that the person undertaking the deployment must be well versed in the use of these tools and may also require that a developer maintain specialized locally developed code to produce the artifacts.
Having to install packages of differing formats to support a multi-component application undermines the desirable goal to employ a single common mechanism. A preferred scenario of course, would be to have a homogeneous package format so that there could be a standard method to create and manage all packages.
Another approach would be to define a package concept that sufficiently describes the characteristics, both essential attributes and dependencies, as well as, encapsulate the lifecycle methods for the package.
This package abstraction offers the benefit of homogeneity by way of its standardized behavior and characteristics yet allows for the underlying differences of the heterogeneous formats and tools needed to support different application components. As new package formats are introduced, their differences can be accommodated by defining a new derived class.
The package abstraction organizes the details of the package life cycle into several categories: configuration, procedures, context and content.
Package configuration encompasses essential installation, version, dependency, storage and deployment attributes. This configuration data is used to drive the package life cycle procedures.
Life cycle procedures fall into two general categories: creation and installation. Creation methods take as input package content and output a package artifact using the format specific to that package type. Additionally, the creation method can store the package artifact into a release repository for later distribution. Installation methods pull the package from the repository, extract it to the host and perform optional pre- and post-installation.
Occassionally, environment specific information is required by the life cycle methods (though one should strive to avoid this), therefore the package abstraction provides the means to override configuration parameters with needed values.
While the package abstraction can be implemented to contain the content of the package archive itself, it is preferable to decouple the content file itself from the code that creates and installs it. With this arrangement the package archive file (e.g, the .rpm file) resides in a repository, while an instance of a package type, provides the configuration and environment context and procedures to install the package.
Structure
There are two primary collaborations of the package abstraction one for building the package and the other for deploying the package.
The Builder uses the Package type to construct, register and store the package. The Deployment object uses the Package to deliver and install the package.
The essential package properties are defined here:
| Name | Description |
|---|---|
| package-arch | Host architecture type. |
| package-base | The package base name. This often is the name of the package
minus the file extension. |
| package-buildtime | Timestamp specifying when the content of the package was built. |
| package-install-rank | A value representing installation order. |
| package-release | The version release identifier. |
| package-restart | Boolean flag specifying that a service restart
is required after installation. |
| package-release-tag | A logical release identification tag. |
| package-filetype | Package format type |
| package-install-root | Directory path where package should be extracted. |
| package-vendor | Organization responsible for creating the package |
| package-repo-url | URL used to access the package artifact from the repository. |
| package-version | Package version |
| package-filename | The name of the package file. |
Example
The Package type defines an object that provides methods to create and install a package and maintain key properties that describe the package. Packaging and deploying the Apache httpd server is a good example to demonstrate the use of the Package type.
The graphic below describes the two phases of the build and installation cycle for a package. In the build phase, a Builder object takes source files and a build configuration and compiles and uses the Package's create, upload and register commands to store it in the repo. In the installation phase, a Deployment object uses the Package's package-install command which implicitly uses the prepare, get, extract and finish commands to acquire and install the package, providing optional environment context during the process.
Check List
Building
- Choose the package format type required. This may be from existing package types like: zip, jar, rpm, etc.). If a new format is desired then derive a new subtype from Package and implement the necessary installation lifecycle methods.
- Identify the set of files that will be archived using the above package format. Then run the create command specifying necessary parameters.
- Store the package artifact in the repository and register it as a resource that can be used as Deployment dependency.
Installation
- Identify Deployment types that require this package type. Possibly, modify the dependency constraints for the Deployment type to allow the new dependency type.
- Choose the Deployment object and Package object and assign the dependency.
- Install the package by running the Deployment object's Packages-Install command.
Rules of Thumb
Since package formats and the tools that produce and manage them are not equal, one must establish a middle ground.
Related Types
Supertype:
Links
- Return to the Core Type Guide
- Package Command Reference
