Deploying Liferay in production - best practice?

[Lior Hadaya，修改在11 年前。]

Hello,
I'm working with Liferay EE 6.1.10. During development I've been deploying my custom portlets/hooks using the hot-deploy folder of Liferay, but I am concerned regarding how this will be done in production.
We know for a fact that Liferay does something (what exactly?) during the hot-deploy process, like changing the web.xml configuration file for example, so I'm worried that using the hot-deploy option is the only way to deploy portlets. I'll explain why this is a concern.

The way I see it there are two issues to tackle in production, the first is how to deploy a Liferay portal instance for the first time on a client's machine and the second is how to update a specific portlet/hook or portlets/hooks on an already running and in-use Liferay server.

Regarding the first issue: When installing a Liferay portal instance in production (for the first time) ideally we would want to be able to run a "silent deployment" procedure, which would preform the following actions:
1. deploy our custom theme
2. deploy our custom hooks
3. deploy our custom portlets
4. create a set of pre-built pages (if I understand correctly this can be done using Liferay's export/import feature on pages. Does importing a page also imports the custom portlets it contains (not Liferay OOTB portlets)?)

By "silent procedure" I mean that I would want it to execute automatically without an installer having to manually copy files or directories, like some kind of script or batch file that can execute everything. Is there any built in support for this? does the Liferay instance need to be up and running during this procedure?

Regarding the second issue of updating an existing portlet/hook on a running production server, I don't think that using the hot-deploy folder on a live production server is a good solution. Are we supposed to just drop the .war file and pray that it would work? what happens if it doesn't work? our portal instance could be in an inconsistent state.
I would prefer to shutdown the Liferay instance, deploy the portlet, make sure it was deployed successfully and then start up the Liferay instance again. I don't want deployment to happen during startup. That's the proper way to upgrade a production server. Is there a way to achieve such behavior?

I would appreciate any input on this, I tried to research the subject but haven't been successful in finding a solution.

Thanks,
Lior

[Llies Meridja，修改在10 年前。]

Dude,

It looks like your thread went unnoticed. However, since it's so long ago that you asked can you share some of your findings here? The reason I ask is that we started using Liferay in production and are facing the same issues.

Thanks in advance.
Llies

[Brian Kim，修改在10 年前。]

Hi Llies,

Can you provide some further details about the setup of your production environment? i.e. version of Liferay, database, app server, etc.

Also, you don't need to use the hot deploy in production. Many of our customers also have that feature turned off. In a non-production environment, you can use the hot deploy folder to build the appropriate webapps folder for you and then use your normal method of deployment.

[Patrick Wolf，修改在10 年前。]

Hi,

I have just come across your concern regarding deployments to a production environment and I am also interested in the best practice to do it.
Usually you may have a pre-production server so that you can test your deployments before they go live. I think also that hot deploy should be turned off in production. My question is how would it be possible, when hot deploy is turned off, to deploy to production without restarting Liferay if you do not have a cluster with fail-over? In production, the service should be available 24/7.

Best regards

[Jack Bakker，修改在10 年前。]

I see A-down 'content' and B-up 'customSoft' where 'A-content' evolves in production and needs to periodically get copied down to staging and dev ; where 'B-customSoft' is in the other direction, from dev to staging to prod

I see need for :

1) convenience scripts for top-down (prod to staging to dev) (A)
2) 'patterns' for dev to staging (
3) en masse script for moving staging to prod(s)

--

[Llies Meridja，修改在10 年前。]

@Jack are you one of those consultants who just want to sound clever so as to confuse the hell out of people and intimidate them into getting their check books out?

[Jack Bakker，修改在10 年前。]

Llies Meridja:

@Jack are you one of those consultants who just want to sound clever so as to confuse the hell out of people and intimidate them into getting their check books out?

LOL, back on earth here: I have real needs to improve: on the one hand how I distribute prod content 'down' to staging and also to multiple dev, and then on the other hand deploying custom from dev 'up' to staging and then having some sort of a script to deploy all 'custom' on staging to production.

[Llies Meridja，修改在10 年前。]

Jack Bakker:

I have real needs to improve: on the one hand how I distribute prod content 'down' to staging and also to multiple dev, and then on the other hand deploying custom from dev 'up' to staging and then having some sort of a script to deploy all 'custom' on staging to production.

Good luck with that - LOL

[Jack Bakker，修改在10 年前。]

Llies Meridja:

Good luck with that - LOL

Funny... however, yes, ok, bad on me to extend the scope of the issue to a broader question on best practices not specifically related to the initial post. My apologies - I have been obsessing lately on approaches for up-down flow and down-up flow.

I think Brian Kim is on track wrt that needing more details on production environment. With a single production (no clustering) while needing proper QA on production after deploy to production... isn't downtime expected ?

[Llies Meridja，修改在10 年前。]

@Kim we're currently using Liferay 6.1.1/tomcat 7 and MySQL 5.5 (wouldn't work with 5.6 hope you get a fix out soon, it's something to do with very long index name if I recall).

The main problem is that hot deployment is crashing the production server more often than not. I am trying to brush up on best practices at the moment not getting paid help.