Introduction
Build time can significantly influence your development speed on SAP Commerce Cloud. Optimizing the build process can greatly enhance your productivity as an SAP Commerce Cloud developer.
In this article, we will discuss how to diagnose build duration issues and provide valuable tips for reducing build time.
Build duration troubleshooting
Total build time
The total time of the build is displayed in the console at the end of the ant task execution.
Build time per extension
There are three main phases during a build:
- Preparation
- Dependency update
- Extension building
Building extensions is by far the most time-consuming phase. To identify extensions with lengthy build time, you should modify <HYBRIS_HOME>/bin/platform/resources/ant/compiling.xml and the 'macrodef' called extension_build such as demonstrated below:
<macrodef name="extension_build"> <attribute name="extname" /> <sequential> <prepare /> <stopwatch name="@{extname}"/> ............... <echo message="@{extname} Build finished on ${finish.time}."></echo> <record name="${HYBRIS_LOG_DIR}/extensions_build_time.log" action="start" append="false" /> <stopwatch name="@{extname}" action="total"/> <record name="${HYBRIS_LOG_DIR}/extensions_build_time.log" action="stop"/> </sequential> </macrodef> |
You will get a log file called extensions_build_time.log with such logs:
Now, with your favourite text editor, open extensions_build_time.log:
- Replace '
[stopwatch] [' by '' - Replace '
sec]' by '' - Replace ': ' by ','
- Search for ':' and replace minutes by the value in seconds (ex:
5:12.413=>312.413)
Now rename extensions_build_time.log to extensions_build_time.csv and open the file into Excel.
In Excel, sort from the Largest to Smallest and calculate the total. Here is an example from my local installation with the full list of 310 extensions extensions_build_time.csv.
Tips
Use SSD Disk with Optimal IOPS
Reading and writing speed of your local disk will have a dramatic influence on the build time. To get the best of the build performance, ensure you run with SSD disk with optimal IOPS (input/output operations per second).
Use ant all in place of ant clean all
ant clean all first removes all compiled / generated files and then build the application. On my local machine, the operation takes 5 min.
ant all builds the application only for the extensions that have changed. On my local installation, the operation takes 30 seconds.
As you can see, using ant all command instead of ant clean all can save you a significant amount of time. However, it's important to periodically use ant clean all to ensure that your build does not include any orphaned files, or to resolve any unusual errors that may arise from a "dirty" build containing outdated files.
Build Within the Extension
If you modify the code of only one extension, you should not run the build for the all set of extensions. By running ant all within an extension, you will speed up the build (on my local installation, from 30 sec to less than 10 sec).
Minimize the Number of Extensions
As each extension contribute to build time, removing extensions that you do not use in your project is critical for the time of the build and restart.
Pro tip: I like to have two installations on my machine that points to the same custom folder using symbolic link and different localextensions.xml: one core installation with the minimal set of extensions required for platform development (back-office, item type, DAOs and service layers) and one with the full set of extensions for storefront development (with extensions such as yacceleratorstorefront).
For this to work, the way you structure your extensions is very important. For a specific extension, you should always try to minimize the dependencies and avoid mixing into a single extension core features and frontend features so you can build core functionalities with your platform setup only.
Most of the development can be done on a core extension that requires only the platform.
This way for most of my development activity, I can use the core installation and when I need to do frontend development, I can switch to the full set of extensions.
On my local machine, the operation ant clean all takes 5 min with all extensions but 22 sec with core platform extensions only.
Build Only When Necessary
A typical developer mistake is to launch a new build for each modification.
Understand when a build is required can save you a lot of time.
Modification | File | Ant build | Update system | Clear hmc configuration | Create essential data | Localize types | Creating project data | Restart server | Hot deploy |
|---|---|---|---|---|---|---|---|---|---|
| Item | /<my_ext>/resources/<my_ext>-items.xml | x | x | x | |||||
| Spring configuration | /<my_ext>/resources/<my_ext>-spring.xml | x | |||||||
| Java | /<my_ext>/src/ | x | x | ||||||
| local.properties | /config/local.properties | x | |||||||
| local.properties (Tomcat parameters) | /config/local.properties | x | x | ||||||
| Backoffice configuration | /<my_ext>/backoffice/resources | x | x | ||||||
| Localization file (website) | /<my_ext>/resources/localization/<my_ext>-locales_en.properties | x | |||||||
| Localization file (cockpit) | /<my_ext>/resources/localization/<my_ext>-locales_en.properties | x | x | ||||||
| CronJob Spring configuration | /<my_ext>/resources/<my_ext>-spring.xml | x |
Optimize smartedittools Extension
'ant clean all' will execute 'pnpm install' and 'rush build', those two actions take minutes to complete and need an active and stable internet connection.
Since SAP Commerce Cloud 2105.6, there is an enhancement and the property smartedittools.only.build.once should be set to true in local.properties so you can skip rush build and pnpm install.
Test your Changes through Effective Unit Testing
Unit testing is a highly recommended practice that not only enhances code quality but can also accelerate your development process. When you run unit tests within your IDE, you can leverage the Java compilation capabilities of the IDE and avoid the need to run 'ant all' every time you make a modification to your Java code.
Reload Code changes Instantly with JRebel
JRebel is a productivity tool used by Java developers to speed up the development process by enabling real-time code reloading. JRebel allows developers to instantly see the impact of their code changes without needing to redeploy their application or restart the application server.
While there is a license cost associated with JRebel, the substantial increase in productivity it provides makes it a highly beneficial investment for any full-time developer.
See Using JRebel SAP Help Page to understand how to setup JRebel for your project.
Please note some that some resources do not support hot deployment (ex: Spring aliases or Backoffice classes).
Setup WSL on Windows
The build time is much slower on Windows compared to Linux/MacOS. For the same hardware, our benchmark shows 4x time slower (from 5 min on Linux to 20 min on Windows).
This is probably due to NTFS poor performance or due to directory junction on Windows less effective than symbolic link on Linux/MacOS.
We recommend developers on Windows to setup WSL (Windows Subsystem for Linux) and perform all their development there.
You can also seamlessly integrate GUI apps (like your IDE) into Windows, see https://arstechnica.com/gadgets/2022/11/windows-subsystem-for-linux-with-gui-apps-launches-for-windo...
Enable Hot Deployment for Backoffice
You can improve the performance of developers of Backoffice extensions by activating the Backoffice Dev toolbar
backoffice.cockpitng.development.mode=truebackoffice.cockpitng.hotDeployment.enabled=true |
You can deploy at runtime Backoffice development.
File type | Tool / method of the hot deployment |
|---|---|
*-backoffice-widgets.xml / *-backoffice-config.xml | Dev Toolbar, F4 + reset everything |
definition.xml and labels of widgets, actions or editors | Backoffice Redeploy Extensions mechanism |
Java classes | JRebel, DCEVM, JVM Hot Swap mechanism, Backoffice Redeploy Extensions mechanism |
Localization labels (for now only in <bo_extension>/resources/bo_extension-backoffice-labels/ - reloading of labels in widgets, actions or editors is not supported yet) | Dev Toolbar |
scss | ant sasscompile, then just refresh browser with reloading of resoruces ( CTRL + F5 ) |
Spring XML files | JRebel, Backoffice Redeploy Extensions mechanism |
zul files, Images | Automatic (just F5) after appropriate properties are enabled |
More details here: Backoffice Hot Deployment SAP Commerce Help page.
Disable your Antivirus or Windows Indexing Service
Any process on your machine that analyses modified files may impact significantly the build time. If you see degradation of the build time, consider adding hybris folder to exclusion list of your Antivirus and Windows Indexing Service.
Decouple Frontend and Backend Developments using Composable Storefront
With headless architecture architecture using Composable Storefront (formerly known as Spartacus), you will be able to split frontend and backend development. It means your storefront team will not be required to execute hybris build anymore and your backend team will reduce their development footprint by removing Accelerator extensions from their build.
Conclusion
Optimizing build time in SAP Commerce Cloud can dramatically improve developer productivity.
By implementing the strategies discussed in this article, developers can significantly improve their development speed on SAP Commerce Cloud.
If you have any additonnal tips to share with the community, please share in the comments.
- SAP Managed Tags:
5 Comments
