Production Upgrades and Continuos Delivery in Liferay 7

[Enrico Costanzi, geändert vor 6 Jahren.]

I'm wondering if liferay 7 and osgi have changed the way people delivers upgrade in production once one ore more bundles have been updated.

On one hand the temptation is to take advantage of the worskpace configuration structure (wich I really like) and distribute the zip generated using

gradle distBundleZip liferay.workspace.environment=production

.
We could then unpack the zip it on the server and deploying the upgrades simply by changing the symbolic link of the liferay home on the production server (taking care of what has to be shared among different version). In this case the whole projects and the bundles could have all the same version

On the other hand its OSGi we are talking about so nothing prevents us from versioning the bundles separately and deploy them at runtime only if they have changed. Let's say we succeed in setting up a continuous delivery environment taking care of deploying new bundles only. My concern is about deploying modules at runtime, especially portlet modules. It seems to us that sometimes interacting with a bundle during it's deployment may cause inconsistencies so that a restart is required.

What are you guys doing in this case? Is there a compromise between the two approaches?

Clarification: I just worked with the CE version under tomcat until now. So some consideration may sound simplistic

[David H Nebinger, geändert vor 6 Jahren.]

Enrico Costanzi:

What are you guys doing in this case? Is there a compromise between the two approaches?

The dist bundle zip option is often used by those who will be spinning up servers in docker containers or other VMs, not so much to overlay in an existing environ. The big problem here would be the zip process does not clean up old files, and sometimes it is necessary to purge osgi/state, work and temp directories during deployment (especially when doing a fix pack or hot fix).

Regardless of your deployment option, you should still be versioning correctly. You don't want folks telling you that version 1.0 is broken, is that the 1.0 from this week or the 1.0 from last week? Versioning is appropriate for tracking, monitoring, and reporting and should not be discarded even if you are doing overlays.

As far as restarts are concerned, there seem to be two different camps here...

First there are the ones who have total faith in the OSGi container. Per OSGi specification, a hot deploy of a new or updated module is just supposed to work. OSGi will unlink old references and rewire new ones. For me, there is a caveat here in that you and your development team (and Liferay for that matter) will always use the right @Reference annotation modifiers to support the unloading and reloading of service references at runtime. I've been developing for DXP over a year now, and honestly I'm not sure that I'm even doing it right all of the time.

Then there are the ones (like myself) that advocate restarts period. Me, I don't care if OSGi does everything right 99% of the time, if that 1% chance results in app server instability and results in crashes, errors or bad UX, I'm not willing to risk it. I am definitely old-school where I care more about application server stability far more than I care about hot deploy convenience. I don't care if it takes 20 minutes for the app server to be ready to return to the cluster and start serving requests, to me it is worth it if I don't have to worry about walking in to a future fire situation because some odd artifact was still hanging around.

I don't think you can be in both camps at the same time, and this would probably devolve into an argument such as emacs vs vi (vi wins of course ), so you should research both options and figure out for yourself which camp you are most comfortable with.








Come meet me at the 2017 LSNA!

[Enrico Costanzi, geändert vor 6 Jahren.]

The big problem here would be the zip process does not clean up old files, and sometimes it is necessary to purge osgi/state, work and temp directories during deployment (especially when doing a fix pack or hot fix).

I'm not sure I understood what the problem is here. The zip file generated from gradle has no osgi/state directory inside. So I guess I can consider it safe and 'clean' when starting this new version instead the old one (wich is supposed to be in another directory, ready to be linked for the possible rollback)

You don't want folks telling you that version 1.0 is broken, is that the 1.0 from this week or the 1.0 from last week?

Of course, what I meant was that the 2 possibilities I have are
1) upgrade the version of all modules regardless wich one of them has changed. Distributing the upgrades with the "distBundle" policy seems to have no drawbacks in this case.
2) versioning each module independently from the others.

But this is the everlasting dilemma about multi-module projects rather than a osgi/liferay/gradle question.

Then there are the ones (like myself) that advocate restarts period

Definitely agree about restart policy

[David H Nebinger, geändert vor 6 Jahren.]

Enrico Costanzi:

The big problem here would be the zip process does not clean up old files, and sometimes it is necessary to purge osgi/state, work and temp directories during deployment (especially when doing a fix pack or hot fix).

I'm not sure I understood what the problem is here. The zip file generated from gradle has no osgi/state directory inside. So I guess I can consider it safe and 'clean' when starting this new version instead the old one (wich is supposed to be in another directory, ready to be linked for the possible rollback)

I believe you were referring to overlaying the new distribution zip on an existing portal deployment, basically providing all updates via zip file overwrites. This is where the "doesn't clean up" issue comes from - a file in osgi/state, for example, from a previous version may not be compatible and could lead to issues.

Of course, what I meant was that the 2 possibilities I have are
1) upgrade the version of all modules regardless wich one of them has changed. Distributing the upgrades with the "distBundle" policy seems to have no drawbacks in this case.
2) versioning each module independently from the others.

The second option is the foundation of semantic versioning and it is what Liferay is moving to. When you version independently you can track changes and bugs independently too. And it seems more natural than "Hey, what are the changes in version 1.1 of module X? Only the version number"

But this is the everlasting dilemma about multi-module projects rather than a osgi/liferay/gradle question.

Yep.