SAP Hybris Commerce Platform Upgrades
SAP Commerce is the engine of your digital business hidden under the hood of an online store. It is the condition of this engine that determines largely the success of the entire project. Therefore, sooner or later you will have to take care of it by providing upgrades or substituting it with a newer version.
In this article, we will answer most of the questions on this topic that bother you and we will help you develop a better strategy for upgrading the SAP Commerce platform for the future.
1. Why upgrade
Most companies using SAP Commerce (formerly Hybris Commerce) have never made a deeper analysis of the reasons why it is worth carrying out regular upgrades of this platform. Only one aspect is taken into account, and this is purely business, namely new out-of-the-box functionalities delivered with the upgrade.
Few people pay attention to such an important issue as safety. Meanwhile, every SAP Commerce upgrade provides many patches to fix minor and major errors. What’s more, the platform contains hundreds of open source libraries and more, which may also have gaps or simply be outdated.
Another important aspect is the maintenance of technical support. After a long time of not making upgrades, the so-called migration debt is dangerously growing within the project. It is very likely that the support for your platform version will expire.
It should also be borne in mind that subsequent versions of the SAP Commerce platform are released on average every two years. After the premiere of the new version, SAP ceases to develop the previous version and does not provide technical support for it. In that case, if something really worrying happens, you will not be able to expect help from the SAP Commerce team. To get it, in any case it will be necessary to migrate the platform to a newer version.
Perhaps a somewhat surprising reason for upgrading the platform, although a very important one from the perspective of the team of developers, is to provide them with the opportunity to work with new technologies.
A developer who for a long time works in the same technology that has not been upgraded for a long period, at some point begins to get bored and looks for other challenges. For most programmers it is natural that they want to work with novelties, with the most up-to-date versions of libraries and in the latest versions of popular frameworks. Otherwise, they become less and less attractive to potential employers and their value on the work market drops significantly.
For instance, let’s take a look at the frontend developers. Even 3-4 years ago, everyone wanted to use jQuery, and today it is difficult to find a job in this industry without knowing AngularJS or React. In the next two years, these solutions – as their predecessors – will be considered obsolete, too.
All available work market surveys confirm that the opportunity to develop and acquire new skills is crucial in the developer’s job. A survey conducted by CodinGame found among over 6,000 developers from around the world have shown that as many as 68% of them consider learning new things the most important part of their job.
Figure 1 — What matters most in a developer job?
Another important reason to upgrade the platform is to gain access to new templates, thanks to which you can increase the productivity of the project team.
In the first versions of Hybris, Apache Ant was used to partially automate the processes of building and installing software, but still a large part of the deployment was performed manually. Later, Maven and Gradle appeared, which significantly improved automation. Recently, Docker is being used more and more often. Moreover, with each new SAP Commerce release, ready-to-use templates for fast dockizing are delivered.
These templates significantly simplify the automation of software building and accelerate its deployment, which translates into a significant increase in productivity. The effects are not visible immediately, but when teams start to use templates consistently, the whole process becomes easier, it can be carried out more quickly, with an ever-increasing degree of automation. In addition, new technologies are also coming up with new upgrades, which further streamline and accelerate the work.
2. When & how often
In general, it is best to upgrade the platform as often as possible, because that is the easiest way. Small steps performed regularly are definitely simpler – especially if you have them tried and tested – than one big leap into the unknown.
If you repeat the process relatively often, you gain more and more skills and the overall cost is gradually decreases.
In one of the enterprise projects, my team performed platform upgrades every two to four weeks. Thanks to the fact that we had developed the appropriate procedure, it usually took about 2 hours, including automatic testing.
Remember that the planned SAP Commerce upgrades should be matched to your own release cycle. If you perform a release once every six months, there is no point in upgrading the platform every month.
In a situation where you plan to make a long “leap” and update the platform, e.g. from version 5.x to 6.x, consider carrying it out with smaller steps. Otherwise, you must be prepared for a much larger, cumulative risk of various types of problems that may occur.
Some time ago, my team carried out a successful SAP Commerce upgrade from version 4.6 to 6.5. It was a large undertaking, so we decided to implement it in two steps. First, we prepared one version – more flexible, not related to the Java update and without major changes in the integration with SOLR, but on the other hand – with a large number of changes in the websites and accelerator façades. The goal was to practice the entire procedure. Subsequently, we made the second step, updating Java and the rest of the platform.
Breaking one large SAP Commerce upgrade into two smaller steps is obviously associated with higher work expenses and a higher overall cost, but the reduction of risk is an undoubted benefit.
The decision whether to make one big step or two smaller depends to a large extent on which versions we are migrating and how significant changes appeared between these versions. In any case, this requires an individual approach and analysis of potential risks.
A separate issue is what versions of the SAP Commerce platform should be used. In my case, I try not to use the latest and usually wait 2 or 3 months for migration to release the new main version, applying only patches to the version we currently use in the project. During this time the SAP Lab has the opportunity to test the new version and release patches to fix the detected errors and security gaps.
3. Required resources
Now let’s consider what resources you need to successfully carry out the SAP Commerce platform upgrade.
First of all, you must have a migration team. In practice, one or two developers will be enough, no more.
If you decide to use a larger number of developers or technicians for this purpose, they will tread on each other’s toes.
Platform upgrade is not a procedure in which everything is always known and can be done according to standard steps, based solely on predefined tasks. You never know how much you have customized the platform and where possible problems may occur. Moreover, all problems should be solved one by one, starting from their source, and not improving the symptoms at the same time in several places.
Sometimes these tasks can be divided between two people, but usually one technical worker is needed to carry out the whole process.
Importantly, the person responsible for the migration does not have to be permanently involved in the project. It can also be a person from the outside. The most important thing is to have a lot of experience in the field.
The next element to ensure is a test environment in which the migration team will be able to perform deployments and verify their results.
This must be a separate, dedicated environment that can be quickly restored to its original state so that the entire migration process can be carried out repeatedly until it reaches a fast and fully smooth automated procedure.
Please note that migration concerns not only the code, but also data and the data migration process should also be tested. Therefore, after migrating the new version of the code, the migration team must always deploy the old version of the database to a fresh environment without the upgrade, and only then apply the upgrade. And this procedure must be repeated many times.
This works in the following way: the migration team creates a copy of the test environment with a copy of the test data. Then, it performs the update on this environment. If it does not work correctly, it finds and solves the cause of the problem, then starts again. And then repeats it until the update goes smoothly.
When planning resources, you must also remember to provide the migration team with help from an expert who knows the specifics of a given project. I mean here a person who has the necessary information about how the project has been customized or knows from whom such information can be obtained.
For example: during migration you encounter a problem that is associated with customization. You have identified the element that is the source of the problem, but you are not able to determine how this element works in the system, what it is responsible for or what it is used for. At such a moment, you must be able to ask an expert who will give you the necessary explanations or will be able to obtain them from other employees.
Such a person will also be indispensable when deciding on the migration strategy, e.g. when there is a problem requiring the project code correction or writing its fragments from the beginning, taking into account the new architecture of the platform. In this case, the task of the expert will be to provide information on how this can be done.
A very important aspect of the upgrade is also having good Case Tests, so that the migration team can independently verify (preferably in an automatic way) whether successive migration steps have been successful and whether they can proceed to the next stage.
Each project is different in this aspect. Ideally, we will get a set of automated tests that will check everything for us. In turn, in less advanced projects, we will need a manual tester who will be able to perform regression tests on his own.
4. How to do it
How to update best the SAP Commerce platform?
First of all, we need to fit it into the current schedule of our own releases. It makes no sense to deploy only SAP Commerce updates for production. It does not contribute much in itself. Maybe there will be some new functionalities in it, and maybe not.
I strongly advise against the approach of freezing the development of new functionalities for the period of the planned platform update. It is very expensive and stops the possibility of working on new features for the end customer in extreme cases even for 2-3 months.
With proper planning and the right approach to quality and process automation, you can implement new SAP Commerce versions in parallel with your own releases. As a result, the platform upgrade becomes one of the features deployed for production together with other changes in the system.
Very often, the separation of platform upgrade from the deployment of own changes in the system is explained by the need to check where the source of the detected error is – whether in the new version of SAP Commerce or in other changes made by the project team. In my opinion, it is the wrong approach, because the separation of both processes generates much higher costs than locating and correcting the error in one common deployment.
Another thing to keep in mind is to provide the migration team with its own version of the code in the form of Git or SVN branch. The migration team will work only on this version of the code and it will synchronize it regularly with the other changes in the project, without affecting in any way the work of the development team.
The main goal of the migration team is to prepare a fully automatic and repeatable update procedure, which must allow for a painless and rapid migration of local development and test environments. It is good practice to verify that each developer can carry out a local migration within a time not exceeding 2 hours. Failure means that migration will not go smoothly and in the case of the production environment we can expect major problems.
Preparation of a manual procedure for developers always involves the risk of many errors during its deployment. Their cause is usually a misinterpretation or misunderstanding of individual steps in the process. Solving these problems requires a huge amount of work.
A very important issue for the migration team is to have their own test environment, which can be easily restored to the initial state (before migration) and verify the entire procedure from scratch. It must also be possible to quickly compare this environment with a reference environment containing the same data and having the same configuration but without the platform upgrade deployed.
If the procedure is ready and you have a stable migration code, it is very good practice to ask 2-3 developers to test it. It is best to create a representative group using different operating systems (Windows, Linux, Mac). Often, at this stage, we detect additional scenarios in the automation that we did not anticipate, making us much better prepared to migrate test environments.
Once you have tested everything and are sure that the update works locally without any problems, it is time to synchronize the changes with the main source code. It is best to do it on the first day of work of the entire team on the new project release. This way, for developers it will be the first task in the new release and their work on new functionalities will not be interrupted or disturbed by this process. This will also allow them to get to know the new version of the platform better, and it will allow more time to test the platform in a broader context (as the whole team will be working on a new, stable version of SAP Commerce).
Thanks to this approach, when you deploy a functionality based on the updated version of the platform, you can be almost 100% sure that the process has been tested in every aspect, and your team is familiar with the changes and will be able to better support the production version.
5. What affects costs
The main factor affecting the costs of the platform update process is Test Automation at all levels.
When we have automated testing, the migration team does not have to test and engage manual testers or other people to verify that the update has succeeded. All they need to do is run automatic testing and they can quickly check if migration has caused any problems in the functionalities.
Manual regression tests are expensive and time-consuming. The need to perform them too often to verify the results of migration generally prompts decision makers to perform upgrades of the platform more rarely. This does not allow to maintain the continuity of the process, i.e. more frequent migrations in smaller steps.
The second important factor affecting costs is the ease of creating environments. It is extremely important if we need to wait for a “fresh” environment with reference data for an hour or a dozen days. This issue can become a bottleneck of the process and block it for many weeks.
The third factor is the length of the leap we have to make. Migration between neighbouring versions is usually quick and painless, and potential problems do not build up and are easy to solve. If we make a leap within several years, we must be prepared for more challenges and extensions of the entire process. Technology and architecture are changing fast, and SAP Commerce is trying to follow the latest trends.
* * * * *
There is no doubt that upgrading the SAP Commerce platform is not a trivial undertaking and, in any case, requires a certain amount of work and money. However, the way it is organized and carried out depends to a large extent on whether it will be torture for your team for many weeks, or it will become almost a routinely procedure implemented relatively quickly and without major problems.
My many years of experience in this matter help me suggest a brief summary, which can be treated as a general clue. The more extensive the automation in the project, including the testing and preparation of environments, and the more frequent update processes, the lower the cost of performing and maintaining it. I hope I convinced you to this approach. And if you have any questions, I invite you to contact our team of experts.