Upgrading to Liferay Portal: How to Migrate a Major Version to the Higher One. Verification and Go Live

The Aimprosoft team has spoken in the previous blog post about Liferay migration concept, stages, estimation principles, and R&D activities. In 3 minutes you will be aware of the considerable part of the every migration process — testing and going live.

Quality verification

It is important to keep in mind that any long-term project is doomed to be re-engineered sooner or later without proper covering by tests. Let’s make clear to the five phases which are a squad in matters of proving the project viability.

Image 1. Liferay migration testing pyramid by Aimprosoft

Phase 1

There is a set of actions doing by users to test a basic functionality and performance capabilities called round trip. As usual, it covers the typical behavior of about 90% of users and is enough to test critical features during smoke testing or automated regression-testing. It is necessary to define a scope of work for testing sprint and to formalize all criteria for correct performance of the forthcoming portal in a UAT sheet.

The User Acceptance Testing document, UAT doc is a short name, is an agreed and signed a certificate of compliance which contains all features expect to be implemented to meet the required specifications.

Certainly, the client has a choice to settle on manual or automated testing. In the former case, it will be a long, time-consuming process but at a lower cost. But in case of choosing automated human behavior simulators which are indeed the cream of the crop, they are able to try the migrated platform dozens of times faster despite the fact that the cost may be driven up a little bit.

At Aimprosoft, we invite QA specialists up till the migration launched. Their role is to bring out critical issues to decrease the impact of possibly arising problems further. Learn more about our software quality assurance testing services, and the development won’t cost you a fortune.

Image 2. User Acceptance Testing document. Fragment

Phase 2

The unit testing is brought into being either in parallel with migration or towards the end of it. By migrating to the higher version, we will have chronicle the whole functionality and initial settings of the previous website and all possible changes to take place on the coming Liferay web portal. That’s exactly what unit tests are applied for. If there are unit tests in the current web portal, they have to be migrated, if there aren’t then developers make them up to avoid possible regressions, which might appear during the further migration process or UAT feedbacks.

Unit cases allow avoiding unforeseen issues for the extension of the system functionality. For example, once happened a client felt like to add an advanced search in the custom portlet, but as it turned out, it didn’t serve adequately. The results obtained with the search had proved to be erroneous. That means the search didn’t work because of regression in the business logic of the application. Thus, unit tests help escape reverting to a more preliminary stage throughout the development rather than testing. As it is already known based on dozens of migrations held, they comprise 20-25% from the entire estimation of time. To prevent the abrupt software regression that makes features stop functioning in the production environment, we reckon, examine the system before migrating along with specific requirements of the client. Neglecting unit testing means jeopardizing a just out Liferay portal, where strong chances to lose clients and money are.

Phase 3

Before validation testing, it is the phase of integration software testing when the sequence of users’ actions are being coded and tested as a group. There is a speed advantage of 10 times faster than manual testing, and the human factor doesn’t carry a lot of weight in it. Headless browsers can help there to emulate the standard browser operation.

To achieve a top-of-the-line product quality, it is advisable here to use Automated Testing Platforms and Cross Browser Testing. Some of the most popular services are SauceLabs, TestingBot, BrowserStack, etc. Similar to unit testing if this kind of tests exist they should be migrated, if not — they should be written by automated software. If someone doesn’t do so, then the time for manual testing will increase greatly, but it won’t help avoid faultiness of about a half of functionality.

100 main variations of user behavior (let’s call it VUB here).

Duration of testing for all 100 variations simultaneously 5 minutes.

Time savings for 5 minutes is equal to 15 mins*100vub= 25 hours of developer work.

At that, we have a bug report 3 days faster at each of testing rounds.

The benefits are huge when it is an active migration process. To compare one developer is able to do smoke testing for 15 minutes, a full test case requires 1-2 hours of him. Any automated testing platform takes only 5 minutes to carry out the whole test cases.

Image 3. Automated testing with a comprehensive platform coverage. Source: SauceLabs

Phase 4

Closed beta testing. Just after the migration has been finished and ready to make a shift to an early access period, then the user acceptance period is coming. It’s a natural step for the project when our client can engage his staff to test the upgraded Liferay portal in production during 1-2 weeks. This trying has been trending to be the most essential for enterprise software testing within a limited amount of time and under the most natural conditions. The development phase is held on while gathering feedback from early adopters. While closed beta testing, we do a code freeze. If proceedings call for the adding new features, then it is possible only after testing is complete.

We confirm that all tests are passed and let our client take his time to test and accept the project. The ways are various:

• to ask for help an external auditor to perform an audit;
• to conduct A/B testing;
• to eat your own dog food.

“Dogfooding”, meaning has taken from Investopedia, is a preferable method at Aimprosoft because we are evangelists of Liferay solutions ourselves and it is standard practice to put to the test a hot piping software. The client’s employees, acquainted with the Liferay collaborative system of the previous major version, experience the renewed functionality from top to bottom and give a valuable feedback which will be taken into account further and the critical needs will be brought to the fore of development milestone.

Phase 5

Going live. Four testing laps have passed successfully, and now the Liferay web portal becomes available for use in full bloom. Moving code to the production environment is planned according to the normal time of using the system. Deployment has no prescribed process. However, there are some slight differences on a case-by-case basis to follow.

The deployment is performed in the least busy hours. For example, Aimprosoft team practises deploying enterprise solutions in 90% of cases on the weekend in order not to block the office operation.

Frankly speaking, it was rather difficult a while back to adjust to migrating Liferay portal for one of our clients (a global provider of translation and localization services) which has offices worldwide. The appropriate time was chosen from 8 a.m to 12 p.m Dublin time zone when it was 10 p.m in California and Sunday in Japan and China. Nevertheless, as the old proverb says, “hard work breeds a harder soul.”

Average time to deploy migrated Liferay web portal from 6 to 7 version takes 2-3 hours minus 1 hour for a preparation period. The preparatory activities include backup, setting up regular backups and failover process. Coming a long way, the process results in the state-of-the-art collaboration space.

The benefits of migrating Liferay with Aimprosoft