Upgrade projects, just like Liferay upgrades, have a lot of unique features making them so difficult and making impossible to have simple, or standard types of upgrade projects. But in our experience, most projects are still optimized for some similar scenario.
Important note: the teams of Webtown work in weekly sprints based on Scrum principles.
Upgrade projects are usually tech-heavy ones and make teams thinking of horizontal layers, but in the world of agile you have to think in vertical way. So we present a kind of "cuvée" of horizontal and vertical breakdown in our upgrade projects. This practically means that, where possible, vertical cuts are made, producing testable, individually valuable parts, but where this is far from the optimal case provided by the tools, we work on the processes horizontally.
Let's talk about Liferay users, and focus on the 6.x -» 7.x upgrades because this is the most frequent case of upgrade projects nowadays. It's not a secret, these projects are the most challenging ones in the league of major version upgrades.
For the sake of simplicity, in the following example we will upgrade from 6.2 to 7.2 (although the script doesn't really contain version-specific elements).
In the project we use as an example, we assumed that the old and new portals should be essentially the same in content, functionality, and image as the most common case, and that the document repository files are in the database for simplicity. The scenario describes the project from the moment we are contracted, agreed to the project, so now we elegantly skip the assessment and risk analysis sections of this section.
For each task, the development team will know what to test and how, and what to do when you start. This is the principle we apply to all our projects. It is also an important element that the development team decides what to keep from the old code, but in the case of third party solutions (e.g. chart library), the solution previously subscribed by the Customer.
We have arrived to the phase of preparation where first we have to get the full backup of the live system, and get the corresponding source code and documentation, so we have the complete solution. We also have access to an integrated, future live or equivalent test environment, where we have all the necessary accesses while enjoying the trust of the customer.
In the next step, as part of the preparation process, we will check the backup we've got to see if it meets the estimation or not. If the amount of content is around the same, or the number of content has increased by 10%, but it is still "the same" type of content, that's fine, it's not a problem. If a new layout is released, it doesn't affect us either, but if we can see new unique features or major changes, we have to talk about it: for everyone it's best because it will change something that needs to be handled.
Let us also clarify that we are developing a scenario for the operation of our customer during the project which will allow them to complete the upgrade process with our support, but essentially without us. This scenario will be written and maintained from day one so that it can be continuously tested for its current status as needed, and this transparency will be of great help to project participants, as they can ask in time if we build the process on an assumption in the scenario that will not materialize. And the team of operation doesn't have to worry about getting an unpleasant surprise in the end.
If we are on a good curve and there is no problem with the backup we have received, we will start working on the database upgrade. On one hand, this is the basis of everything, and on the other hand, we get a tool from Liferay that does the job for us. Usually it takes a couple of days to reach the status of the first successful, few-hours-long run of it, while handling all the features that one of the scripts can cool off.
In case of success we find ourselves in the position shown on the illustration above.
The green area exactly is what we have and can be tested. This contains two things at the moment:
The database has been upgraded to 7.2 and we have a Liferay DXP 7.2 freshly unpacked and running.
So at this stage there is no unique design or unique development on our portal, only the content of the database is different from a newly downloaded and launched Liferay. Testing this phase obviously focuses on content cardinality, which is the quantitative testing of pages, documents, users, categories, and many other database contents.
If the outcome of these "tests" is ok, then we have a baseline that have to save for later, and we have an experience of how long it will take to get to this phase and how much work it will take to do it again. These time frames will be useful inputs when the migration time window, code and content freeze topics will be planned in the future.
As a second step, we create a design for the portal but only for those parts, where we have the backend code that will be used in the future. Usually this means the Liferay modules, and the basic elements that are part of the theme (eg header, footer, page layouts, etc.) as well. In our project, just like in the majority of upgrade projects, there is not so many reusable code parts in this phase. Because the world of frontend evolves very quickly and Liferay has a 7-year-long product life cycle. But reusing a code part or not, is always a decision of the development team. If keeping certain parts of the old code is an exact requirement, then the team has got the information and knowledge about the part long time ago, so they will keep them and add them to the new design.
The result of this phase is a portal that provides a whole crawlable web experience, and since only custom upgrades and previous hooks, ext-s are missing, now it is ready for design testing. Different devices, different browsers are being involved, and we use automated crawler solutions (crossbrowsertesting.com, cypress.io). in the process of design testing.
This phase already brings manual - and usually automated - steps into our scenario, such as changing the velocity template to freemarker or portal-ext settings for proper operation. The templates have been created during the phase, but the templates will need to be replaced when we do the publishing process.
When all the tests are done and successful, the status we've reached in this phase is visible and valuable to everyone. It's especially valuable to give a demo to the stakeholders.
We have reached the point where the following steps are unlocking and upgrading the custom developments, hooks and ext-s. In order of priority, we focus on starting with the most risky and / or most valuable business features. We emphasize that all functions in this project must be preserved, which was previously validated before the agreement. In the case of a purely agile contract, well, some of the portlets from the end of the queue could be smoothly missed, because meanwhile it turned out there's no need for them in the future.
In this phase we are thinking about vertical cutting.
It means that when lifting a custom widget, the backend and frontend code are created together, so widgets can be tested.
In this phase, the team goes through the backlog elements and the principle is that custom portlets will be migrated to the widgets first, and the functionality of ext-s and hooks have to be discussed with the customer first and then we can create them in the new system.
Testing is continuous throughout the phase, so we have a well checked environment when we get to the end of all the custom developments.
The migration time window can vary in many ways, from shorter concurrent operations to a quick weekend transition, but the next step is definitely the go-live of the new solution, running the entire process with fresh, live data, documented and tested based on the upgrade scenario.
Fortunately, we have proposed a 20% credit allocation of optimization and for the post-arming phase and refactoring the list of the technical dept, so we have the chance to analyze the whole environment.
Why is this important?
Because Liferay DXP 7.2 gives us plenty of brand new features, brand new ways of thinking about the structure and the functionality of our new portal.
And now we have the chance to rebuild some parts with taking advantage of the DXP mindset.
And we can publish these parts in independent releases.
____________________________________________
If you'd like learn more about the importance of Liferay upgrade, click here:
https://www.webtown-group.com/liferay-upgrade
To learn more about Liferay DXP, click here:
https://www.webtown-group.com/liferay-digital-experience-platform-dxp
To ask for consultation, click here:
https://www.webtown-group.com/upgrade-quote
