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 JavaArchives) 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 :-)