Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
Is there any better way to automate Liferay configurations
Hello All,
We have planned to automate, the movement of liferay related configurations (Create page, Custom field, DDL etc) from UAT env to Production env.
We would like to maintain the configurations added/updated/removed in each deployment so that it would help us to revert the changes to a particular version.
Below are the possible solutions we found.
1. Using Lar import and export.
2. Using Remote staging
3. Insert/update related Liferay table using Scripts.
4. Create custom configuration importer which reads configuration from a file and export to another system.
Challenges we are facing with the above approaches .
1. Using Lar import and export.
a. Configuration data from one environment to another may change
for example : Web service End point URL configuration in custom field or in DDL is different for different environment.
b. Lar file export in target system may fail due to mismatches in the configurations between source and target system.
From our past experience, we have faced above problem and had spent lot of time to rectify the mistake.
2. Using Remote staging.
a. Due to security constraints, we do not have the access to Production server from UAT server.
3. Insert/update related Liferay table using Scripts.
a. We do not want to use this approach as Liferay suggest not to insert or update Liferay tables directly ...
4. Create custom configuration importer which reads configuration from file and import/export to another system.
Pros:-
a. We have planned this approach to move all the configuration related to (Create page, Custom field, DDL etc)
b. We will maintain all the configuration details in a file. Importer will read this file and import the content in different environment.
c. Easy to revert the changes to particular release as we maintain the configurations in a file which can be versioned in SVN ..
Cons:-
a. Required Customization
b. Moving webcontent changes from one evniroment to another
Please comment and suggest on the approach also please suggest if there are any better way to automate the configuration movement from
one environment to another.
We have planned to automate, the movement of liferay related configurations (Create page, Custom field, DDL etc) from UAT env to Production env.
We would like to maintain the configurations added/updated/removed in each deployment so that it would help us to revert the changes to a particular version.
Below are the possible solutions we found.
1. Using Lar import and export.
2. Using Remote staging
3. Insert/update related Liferay table using Scripts.
4. Create custom configuration importer which reads configuration from a file and export to another system.
Challenges we are facing with the above approaches .
1. Using Lar import and export.
a. Configuration data from one environment to another may change
for example : Web service End point URL configuration in custom field or in DDL is different for different environment.
b. Lar file export in target system may fail due to mismatches in the configurations between source and target system.
From our past experience, we have faced above problem and had spent lot of time to rectify the mistake.
2. Using Remote staging.
a. Due to security constraints, we do not have the access to Production server from UAT server.
3. Insert/update related Liferay table using Scripts.
a. We do not want to use this approach as Liferay suggest not to insert or update Liferay tables directly ...
4. Create custom configuration importer which reads configuration from file and import/export to another system.
Pros:-
a. We have planned this approach to move all the configuration related to (Create page, Custom field, DDL etc)
b. We will maintain all the configuration details in a file. Importer will read this file and import the content in different environment.
c. Easy to revert the changes to particular release as we maintain the configurations in a file which can be versioned in SVN ..
Cons:-
a. Required Customization
b. Moving webcontent changes from one evniroment to another
Please comment and suggest on the approach also please suggest if there are any better way to automate the configuration movement from
one environment to another.
Start by reading: https://community.liferay.com/blogs/-/blogs/content-creation-is-not-a-development-activity-
1. Lars are too fragile and in no way can you handle some sort of "content rollback" using lars.
2. Remote staging is not to be done between environments. One production node/cluster is set up for staging, another is the live cluster. They are both production environments and must be treated as such. In no way is remote staging meant to simulate some kind of crazy content promotion scheme.
3. Never, ever ever modify the Liferay database. You have no idea what table(s), search indexes, cluster-wide messaging, etc goes on for a typical content insert. Trying to manually do this via scripts is just begging for a complete outage after you've corrupted the data.
4. This is a heck of a lot of work, you're going to spend more time building out this toolchain than you will actually managing the data.
Content creation is not a development activity. You first got things wrong by wanting to create content in the lower lanes and then promote it as if it was code through the higher lanes. That is not content's path, content follows a standard publishing model, not a development model.
Your lower lanes are for testing code: portlets, themes, fragment bundles, etc. You might even use it to test ADTs and site/page templates. But at the end of the day, the content you're testing with in there should be considered not much beyond generated Lorem Ipsums.
Some folks will push back saying "I need to see how my great web content is going to look when it is rendered in the actual theme" or some kind of nonsense. That is what staging is for, where the content can be created, viewed, edited and tweaked before live site publication.
1. Lars are too fragile and in no way can you handle some sort of "content rollback" using lars.
2. Remote staging is not to be done between environments. One production node/cluster is set up for staging, another is the live cluster. They are both production environments and must be treated as such. In no way is remote staging meant to simulate some kind of crazy content promotion scheme.
3. Never, ever ever modify the Liferay database. You have no idea what table(s), search indexes, cluster-wide messaging, etc goes on for a typical content insert. Trying to manually do this via scripts is just begging for a complete outage after you've corrupted the data.
4. This is a heck of a lot of work, you're going to spend more time building out this toolchain than you will actually managing the data.
Content creation is not a development activity. You first got things wrong by wanting to create content in the lower lanes and then promote it as if it was code through the higher lanes. That is not content's path, content follows a standard publishing model, not a development model.
Your lower lanes are for testing code: portlets, themes, fragment bundles, etc. You might even use it to test ADTs and site/page templates. But at the end of the day, the content you're testing with in there should be considered not much beyond generated Lorem Ipsums.
Some folks will push back saying "I need to see how my great web content is going to look when it is rendered in the actual theme" or some kind of nonsense. That is what staging is for, where the content can be created, viewed, edited and tweaked before live site publication.
Copyright © 2025 Liferay, Inc
• Privacy Policy
Powered by Liferay™