Deployment Process

[alistairp781078]

We've recently been getting Java compilation errors during our deployments that have resulted in us either having to manually edit JSPs in /crx/de or update the bundles in the system console.

The following is our deployment process and I was wondering if anyone could advise on whether this a good/standard deployment procedure and if there are any changes we could make to it:

1. Build a job in Jenkins that essentially pulls a specified branch or tag from Git and runs the following Maven command: clean install -PautoInstallPackage
2. Invalidate the caches and rebuild the clientlibs here: /libs/granite/ui/content/dumplibs.rebuild.html
3. Replicate the ui.apps package from /crx/packmgr
4. Replicate the /etc/designs and /etc/clientlibs folder using the /etc/replication/treeactivation tool.

[vjetty]

Scott is right Alistairp. It's not best practice to replicate large packages when you deploying, instead install them on publisher as you are doing it on author side. 

[Jörg_Hoh · Accepted solution]

Hi,

How do you control if your maven job was succesful? IIRC maven does not complain if your content package contains invalid XML which cannot be imported into the repository, so you cannot really rely on it.

Also, how do you deploy product fixes (Hotfixes, Servicepacks, Cumulative Featurepacks)? Deploying them through maven can work, but not reliably. Imagine a case, when a hotfix contains a new version of the Oak repository, which is going the restarted immediately (during the deployment process).

Regarding the way how you deploy your publishs:

• Your current approach does not replicate bundles
• You deploy all publishs at once, which will likely cause downtimes on publish side (always bad)
• Why do you replicate the design and the clientlibs via tree activation? Aren't these information part of any content package?

HTH,
Jörg