Packaging in Triple’A+ was imagined as a very simplistic scenario. The assumption was that we would do a one-fit-all package to deliver adaptation via Design Studio. The reality is not a simple as designed. Soon after the roll-out of TAP R11, developers needed to overcome the limitation that a workspace in Design Studio can host only one packager project. Luckily, it was/is possible to get rid of it and a small improvement in the custo-packager template can ease the setup of a build.
The journey of a package
If one looks at the roll-out of a package to production as a transport process, the development has to be wrapped as an “installable” and conveyed from checkpoint to checkpoint: development, integration, user acceptance, production. Each step requiring validation to progress till the endpoint. This journey is made possible with the custo packager.
The project template allows to create a customization package which can include several projects present in the workspace. The actual limitation of the template is that it doesn’t consider the variable “custo-name” inserted in the wizard setup and assumes that only one packager project type is needed/required per workspace. Whatever is filled in, the project name will be “custo-pms-packager”.
Divide & conquer
A one-fit-all package is not a good idea when a package has to cycle through several environments of different configuration. Packages are cumulative for the WUI installer. Generating one package reduces the flexibility offered by the installer. Moreover, after Triple’A+ 1.30.6, the installer was reviewed in order to shorten the installation procedure: all the packages are extracted and merged within the same repository first, the effective installation taking place in a second time.
Another reason not to do so: the WUI can be delivered internally and as a portal or part of one. Some configuration aspects may be necessary only in one of them. Therefore, isolating this difference in a separate package would allow to test a package that is common to both instances, the second one having the complement only. I often had this situation where one of the two production instances requires additional patches (HTTPS, Corda redirection, secured cookie, timeouts,…)
What about building 2 or more packages from the same packager ? In essence possible but not practical. Example: creating a package to deliver the pms-models takes 1/2h and is build frequently. Whereas a package that contains a configuration patch needs only a few seconds and as it doesn’t change much, is built less regularly. Why would you wait 30min for a 2s package? What if the build fails ? Spend 30 more mins…
Splitting/Dividing allows also to package by purpose or specifically for an environment. More generally speaking, the flexibility one gain hedges the effort to set it up. And so far by experience, system administrators prefer to manage smaller configuration and not mix their patches with the front end customization.
How many packages then ?
On the other hand, too many packages can reduce the efficiency that we gain. Moderation is advised. I usually propose to deliver:
- one package that is environment independent and
- several packages that are applied specifically to an environment or to fulfill a purpose.
We implemented this strategy at work and have the following situation:
- common-pms-packager: for a common package which holds the pms-models and “custo-manual” project types like the customization equivalent wui-pms-models-manual, wui-default-profile-manual or nls-en-manual,…
- registry-pms-packager: builds a package containing the otf-registry keys to use in the configuration and patches
- config-pms-packager: builds a package for the configuration and patches. Includes usually custo-config, custo-lib, custo-install project types
- <env-name>-pms-packager: environment specific package that holds patches to be applied for a specific environment
After a rollout, most of the packages are stable. When the number of packages to deliver becomes important, they can be grouped. Example: when adapting the configuration of the TSL, a separate package can be provided to facilitate the delivery and decouple it from the rest of the adaptation. As soon as the package is validated and stabilized, it can be added to an existing package.