Deployment Process | Community
Skip to main content
A
alistairp781078
Level 4
April 6, 2017
Solved

Deployment Process

  • April 6, 2017
  • 2 replies
  • 1306 views

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.
This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by joerghoh

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

2 replies

vjetty
vjetty
Level 4
April 6, 2017

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. 

joerghoh
Adobe Employee
joerghohAdobe EmployeeAccepted solution
Adobe Employee
April 6, 2017

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

Terms & ConditionsAccessibility statement

Loading footer...