A parallel development infrastructure was deployed to avoid interrupting and / or blocking the different teams that are responsible for evolving the developments of the Extranet. The infrastructure is based on free software projects such as SVN, Maven, Gradle and Jenkins. One of the challenges of the project, and in any product upgrade, is how to organize existing projects and development companies while continuing its Liferay 6.2 life cycle.
Given that Liferay DXP 7.0 does not support sharding in the database, a pre-process of the upgrade was drawn, together with the Liferay Support team, in order to adapt the Liferay Portal 6.2 with sharding to a Liferay Portal 6.2 without sharding ( with a single shard). This pre-process consisted of three phases:
• A first phase that consisted of the unification of shards through generic scripts and independent of the environment where they were launched. That way it was possible to merge all the tables of the 4 shards.
• A second phase that consisted in raising the Liferay Portal 6.2 pointing to the new database with a single shard.
• A third phase that consisted in validating together with the users that no data was lost during the first phase.
Once the pre-upgrade process to unify the shards in one was passed, the procedure was drawn up to migrate the three environments (development, preproduction and production) to Liferay DXP 7.0 through the upgrade process defined by Liferay.
To train the Liferay DXP core upgrade procedure, production data were used in all three environments. In total, the upgrade process of the core was executed four times:
• In the development environment.
• In the preproduction environment.
• In the production environment. This iteration was aimed at training the production machine and anticipating potential problems with the machine or connectivity to external services.
• The second and final iteration in the production environment.
The stack used is certified by Liferay, and uses Red Hat as the operating system, Jboss as an application server, Elastic Search as an indexing and search engine, and Oracle as a relational database.
The strategy for the migration of the developments was to identify which developments could continue to work in compatibility mode and which developments, due to their idiosyncrasy, should be migrated to OSGi modules (themes and projects of type service builder). Compatibility mode allows you to maintain the same project structure without having to migrate the portlet to OSGi by changing the references to the new Liferay APIs.
The subjects had to be updated to Gradle through the use of Yeoman, which are part of the Liferay recommendations. CSS styles were affected by changes in the structure of the page in DXP version. The use of the Bootstrap 3 libraries as well as the Automatic Single Page (SPA) in Liferay DXP also required some adaptations.
The use of OSGI modules in the portlets also required certain changes, for example, when making a configurable portlet in Liferay DXP. The adoption of an OSGI architecture incorporates many advantages to the product, but it will require numerous changes in those upgrade projects between versions 6.2 and 7.x, which have many customized and developed components.
The production was carried out smoothly, controlled and without setbacks, under strict revision and validation work, with a portal under Liferay DXP equivalent in terms of functionality and appearance. Due to the changes introduced in the product architecture in the DXP version, to a modularized OSGI architecture, this was a considerable challenge.
Currently, in the company's Extranet portal, there are several websites with several developments (among themes, portlets and extensions of Liferay there are around 30 projects) developed with different frameworks such as (MVC, Service Builder, Spring MVC ...) as well as different task automation tools (Maven and Gradle).
