The granule of deployment is a collection of software which is deployed (released to customers, whether internal or external) as an atomic unit. (This does not necessarily mean as a single file). A GranuleOfDeployment should contain one or more GranuleOfReleases. Note that the GranuleOfDeployment may be, and frequently should be, coarser than the GranuleOfRelease.
The GranuleOfDeployment is frequently referred to by any or all of the following names, not all of which are necessarily correct:
- Library
- Shared Library/DLL
- Component
- Archive
- Cabinet
- Application/Applet
Some argue that the GranuleOfDeployment should be equal to the GranuleOfRelease. This may be convenient for developers and expert users, but may be a pain for end-users who aren't interested in fine-grained (even at the GranuleOfRelease level) dependency tracking. RpmHell is a well-known example (in the Linux world) of exposing fine-grained dependencies to the user (coupled with an inadequate packaging tool). However, when multiple granules of release are aggregated, problems that can arise.
The GranuleOfDeployment should have the following properties:
- The GranuleOfDeployment should be tracked/trackable by the OperatingSystem/VirtualMachine/etc.
- All such granules, except for "application-level" granules which are not subject to dependency by other modules, should be versioned in some fashion.
- There must be no cyclic dependency between granules of deployment. Note that it is possible for a cycle to arise between two granules of deployment even though there is no cycle among the constituent granules of release.
GranulesOfDeployment may have the following features (it can be argued that this is a should requirement where the GranuleOfDeployment contains more than one GranuleOfRelease).
- It should be possible for the runtime to "extract" granules of release from the granule of deployment--shared archives (such as JavaArchive) have this capability. (Ordinary DLLs do not).
- Otherwise, a single granule of release might be present in multiple granules of deployment, possibly producing conflicts should both granules of deployment be needed.
See GrainOfSalt :-)