How to move Liferay portal from local to ProdHow to move Liferay portal from local to Prodhttps://liferay.dev/en/c/message_boards/find_thread?p_l_id=119785333&threadId=373167662024-03-29T12:58:32Z2024-03-29T12:58:32ZRE: How to move Liferay portal from local to ProdOlaf Kockhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1161900782019-09-16T06:36:50Z2019-09-16T06:36:50Z<div class="quote-title">Games BX:</div><blockquote><br />I also have the same needs as you and have not resolved, it is still in conflict, whether anyone has a solution or not<br /></blockquote>Please elaborate on "the same" - there's plenty of information already here, instead of repeating everything or adding more details to <em>all</em> the answers, techniques and recommendations, we'd need to know what you're struggling with.Olaf Kock2019-09-16T06:36:50ZRE: How to move Liferay portal from local to ProdGames BXhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1154634842019-09-14T02:59:03Z2019-09-14T02:59:03ZI also have the same needs as you and have not resolved, it is still in conflict, whether anyone has a solution or not<br />GAMESBXGames BX2019-09-14T02:59:03ZRE: How to move Liferay portal from local to ProdDavid H Nebingerhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1152496392019-09-10T18:22:16Z2019-09-10T18:22:16ZSpot on!<br /><br />The point I was making is that, while schema version is one particular use of upgrade processes, it's not the only thing they're good for...David H Nebinger2019-09-10T18:22:16ZRE: How to move Liferay portal from local to ProdAlberto Chaparrohttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1152447512019-09-10T17:52:06Z2019-09-10T17:52:06ZSometimes we have our differences regarding the purpose of upgrade processes but this a nice explanation about what we can do with upgrade processes. Maybe the definition for an upgrade process is any kind of data modification your module needs to be able to work adequately in its next version.<br /><br />Apart from this, it's important to clarify that we follow the formula <strong>MAJOR.MINOR.MICRO</strong> to define the schema version per every upgrade:<br /><ul style="list-style: disc outside;"><li><strong>MAJOR</strong>: when you make a breaking schema/data change which will prevent interaction with the previous version of the code (Ex: alter a column name, removal of table/column, adding a new table/column and some logic to migrate the data to the new entities, adding some data required for the app to work, etc.)</li><li><strong>MINOR</strong>: when you make a schema/data change that is compatible with the previous version of the code. These kinds of changes differ from micro-changes in that the modification is required for the new code to work (Ex: adding a new table/column without modifying the current data)</li><li><strong>MICRO</strong>: when you make a schema/data change that is compatible with the previous version of the code (Ex: increase the length of a varchar field, modify data to solve a bug with the current logic: modify some database indexes, adding some optional data, etc.)</li></ul><br />Thanks.Alberto Chaparro2019-09-10T17:52:06ZRE: How to move Liferay portal from local to ProdValérie Lehmannhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1152475562019-09-10T14:26:19Z2019-09-10T14:26:19ZThanks a lot for your detailed explanations! We'll have a look at it shortly...Valérie Lehmann2019-09-10T14:26:19ZRE: How to move Liferay portal from local to ProdDavid H Nebingerhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1152459492019-09-10T13:48:24Z2019-09-10T13:48:24ZSite initializers are part of 7.2 but there's not a lot of documentation available on them yet.<br /><br />Don't let the name, "upgrade process", constrain the use for these valuable tools. They are more than just "upgrade from one Liferay release to another", they are processes which run and are defined by your module version changes, too.<br /><br />So forget about Liferay upgrades for a second, let's just consider a simple module, Foo. Let's say that Foo is a module that knows how to find and return Bar objects from some data sink, whether that is a web service, a mongo DB, or even some kind of flat file. So Foo works fine but you realize that when deploying to a new environment, there are no Bars available and users find it a bit frustrating.<br /><br />So how do you have an initial set of Bars available? Well you can use an upgrade process. Define a process that handles the 0.0.0 -> 1.0.0 version (0.0.0 represents a "not deployed before" version) and all it does is populate some Bars. When your module gets deployed to a new environment, the upgrade process would automatically run and create the Bars that Foo will be able to return.<br /><br />When you create version 2.0.0 of Foo, perhaps part of that is a change to the Bar object, like new fields are added or removed or types changed. But you have all of these existing Bars in the data sink, how do you deal with those? Normally as developers releasing internally we'd work with the DBA to make the changes, maybe have some SQL scripts to adjust the data, etc., all requiring a big coordinated deployment effort to get the release done, and hopefully your plan includes some testing and rollback processes in case things go awry or the deployment process is not followed precisely...<br /><br />But we can simplify all of that by building an upgrade process from 1.0.0 -> 2.0.0 that would take care of applying the DDL changes to the Bar data source as well as updating existing Bars in the data source to conform with the new Bar model. It's now a controlled process that is guaranteed to run in order, applying all the changes that are necessary on each deployment to a new environment, plus you can build-in testing routines to verify that the new Foo and the Bars are all functioning correctly. Call it a deployment verification "upgrade process".<br /><br />The sky is really the limit on the upgrade processes. Site initialization can be handled in a similar fashion; write an upgrade process from 0.0.0 -> 1.0.0 that leverages the Liferay APIs to create a site, pages, web contents, users, roles, yada yada yada. You get full access to the Liferay APIs (something RI is not going to give you), you are guaranteed to run only once (after the 0.0.0 -> 1.0.0 process runs, the environment will know it is at 1.0.0 and not try to re-execute the upgrade process again), and you can start to leverage your own data format to feed into the upgrade handling (imagine creating your data records as JSON instead of the cryptic RI XML files and your upgrade process reads the JSON and invokes the Liferay APIs to instantiate the objects)...<br /><br />The upgrade processes can really accomplish a lot for automated environment preparation, you just have to get beyond thinking that upgrade processes are only for moving from one Liferay release to another...David H Nebinger2019-09-10T13:48:24ZRE: How to move Liferay portal from local to ProdValérie Lehmannhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1152363922019-09-10T06:19:05Z2019-09-10T06:19:05ZHi David,<br />Thanks for replying so quickly!<br />I am glad to get the confirmation that the RI still exists in LR 7.x.<br />Is the Site Initializers already available in 7.2 or does it come with 7.3?<br />As far as I know, the upgrade processes are used to update a portal from a Liferay Release to another Liferay Release. As far as I know, the update processes are not the tools to use when we update a portal when the Liferay Release remains unchanged but we want to update the configurations of the pages and portlets of a portal on all environments. Is that correct?<br />What do you mean with " scripting control panel"? What is it? Any useful links to share about this?<br />Best regardsValérie Lehmann2019-09-10T06:19:05ZRE: How to move Liferay portal from local to ProdDavid H Nebingerhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1151590512019-09-09T21:30:17Z2019-09-09T21:30:17ZI'm actually doing a talk on this kind of thing at <a href="https://www.liferay.com/web/events-devcon">DEVCON</a>!<br /><br />RI is still there, as are the new Site Initializers, upgrade processes (my personal fav) and even scripting control panel.David H Nebinger2019-09-09T21:30:17ZRE: How to move Liferay portal from local to ProdValérie Lehmannhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1151406792019-09-09T16:19:29Z2019-09-09T16:19:29ZHi all,The solution David described is fine if you only have contents to publish into production. In that case the staging mechanism will be indeed the right one. For our requirements this is not enough though! <br />In 6.2 we used to use the resources importer. This tool did the trick for us. If a portal contains a certain amount of pages, each of them displaying a certain amount of portlets, and if those portlets all are configured differently, you will need to use the resources importer to define your pages into all your environments, including into production. My question is now: what is the best practise in liferay 7.2 or DXP to fulfil the requirements I explained above? Is there a resources importer or similar tool to do so in Liferay 7.2 or DXP? E.g. to define all your pages, portlets, roles, custom fields, etc into all environments?Valérie Lehmann2019-09-09T16:19:29ZRE: How to move Liferay portal from local to ProdJan de Gorterhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=449628422014-11-06T13:38:24Z2014-11-06T13:38:24ZI also would like to be able to do this! <br /><br />I created on both instances ("acc" and "prod") a site "MySite". Trying de lar archive site export/import (export from "acc" and import on "prod") i encountered an error during import:<br /><blockquote>An unexpected error occurred with the publication process. Please check your portal and publising configuration.<br />com.liferay.portal.NoSuchGroupException: No Group exists with the primary key 16639</blockquote><br /><br />Some details:<br />The "acc" and "prod" instances are running the same version (In the "Control Panel" -> "Configuration" -> "Server Administration" the version information reports for both instances: "Liferay Portal Community Edition 6.2 CE GA2 (Newton / Build 6201 / March 20, 2014" )<br />I created and exported the site from one environment ("acc"). Here in the database there is a record in the "GROUP_" table with "GROUPID" = "16639" (this is also shown as "Site ID" in the "Site Settings" page). In the database for the "prod" environment there is no record for this "GROUPID" The creation of the "MySite" did not generate the same "GROUPID". This is possible since after running both instances i was trying different scenario's and i did not start with an entire fresh install before attempting the import. Despite this i would like to be able to export a site and move it to production (overwriting an existing one at the prod instance)!<br /><br />Altough i am going to look into the "Liferay's staging support" i am curious what should be in place to be able to use the import/export site method for moving sites between environments.Jan de Gorter2014-11-06T13:38:24ZRE: How to move Liferay portal from local to ProdDavid H Nebingerhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=446363682014-10-30T16:05:19Z2014-10-30T16:05:19ZYou shouldn't be developing content in dev, content creation should be going on in prod.<br /><br />Alternatively you can look at Liferay's staging support (depending upon the version, this may or may not work) or LAR export/imports (this only works when Liferays are running the same version).<br /><br />But content creation should not be considered a classic development activity going through the same sort of promotion process.<br /><br />A database dump and restore to prod is risky in that you'd have to dump all of your production data. If you are going to do this, remember that you should also copy the data directory so the backing files are also copied, but this will not be a viable long term solution.David H Nebinger2014-10-30T16:05:19ZRE: How to move Liferay portal from local to ProdI-A Kotopouloshttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=446302802014-10-30T14:22:52Z2014-10-30T14:22:52ZI have the same need. I can definitely deploy any portlet I have created using the war files. But what about the pages, users, custom fields etc. Your suggestion is to fully dump the database and restore it in the new machine?I-A Kotopoulos2014-10-30T14:22:52ZRE: How to move Liferay portal from local to ProdDavid H Nebingerhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=373162652014-04-30T04:07:46Z2014-04-30T04:07:46ZOkay, somewhere you were led astray.<br /><br />A development server should be used for development. You create portlets, themes, etc. These each get compiled and built as separate war files so they are easy to deploy to production when you're ready. It is not for you to develop content, manage users, etc.<br /><br />Those later things you should do directly in your production environment. Optionally you can set up a staging environment for the content, but that's a separate discussion.<br /><br />I'm sure folks will say do the export/import thing, and with many of those eventually you may get most of your stuff, but unless you're willing to zip up your environment (including the data directory) and export your full database, then overlay that into production, I predict your chances of a complete transfer run around 90%-95% if you really know what you're doing but they drop if you don't.David H Nebinger2014-04-30T04:07:46ZHow to move Liferay portal from local to ProdArun R S Chandran