SeaLights Node.js agent - Deploying Instrumented code
- Marc Amouyal
After generating a new folder with the instrumented code of your Front-End application, the content of this folder needs to be deployed instead of your original code on the server for the client browser to work against. Below, you’ll find several Best Practices in use among Sealights customers:
In the sample commands below, we refer to your application’s artifact as dist folder, as a default.
Please make sure to update the command according to your specific configuration, and replace the parameter with the path relevant to your project's settings. For example: apps, code, js,…
Deploying the folder containing the instrumented code
For example, if your original folder was named 'dist' and the new folder with the instrumented code is 'sl_dist’, you can follow the steps below:
Rename the original folder from ‘
dist’ to ‘dist_original’Windows OS: rename dist dist_original Linux/Unix OS: mv dist dist_originalUse the instrumented folder instead of using one of the following options by renaming the ‘
sl_dist’ to ‘dist’Windows OS: rename sl_dist dist Linux/Unix OS: mv sl_dist dist
On Unix/Linux system you also have the ability to define a ‘dist’ soft link to the ‘sl_dist’ folder.
ln -s sl_dist dist
Deploying Instrumentation for several environments (Lab IDs)
If you need to instrument your front-end application for several environments and provide accordingly different LabIds (resp. to every context), additional commands are required to manage LabID parameters in your deployment steps. We have described below the most common solutions in use
Using slnodejs agent
You have the ability to split the single slnodejs scan command into a build scan command and several “instrumentations only” commands. For example below, we’ll instrument the application for two different LabIDs (MyFirstLab and My-2nd-Lab)
#Build Scan without Instrumentation - Unix
npx slnodejs scan --tokenfile /path/to/sltoken.txt --buildsessionidfile buildSessionId --workspacepath dist --scm git --projectRoot /path/to/source/root
#Instrumentation for first environment (i.e. MyFirstLab)
npx slnodejs scan --tokenfile /path/to/sltoken.txt --buildsessionidfile buildSessionId --labid MyFirstLab --instrumentForBrowsers --instrumentationOnly --workspacepath dist --outputpath sl_dist_MyFirstLab
#Instrumentation for second environment (i.e. My-2nd-Lab)
npx slnodejs scan --tokenfile /path/to/sltoken.txt --buildsessionidfile buildSessionId --labid My-2nd-Lab --instrumentForBrowsers --instrumentationOnly --workspacepath dist --outputpath sl_dist_My-2nd-Lab Using a Search and Replace operation
Another solution is to execute the slnodejs scan --instrumentForBrowsers command with a generic labid that is replaced in the JS files (string operation) prior to the artifact deployment in each environment
Unix:
npx slnodejs scan --tokenfile /path/to/sltoken.txt --buildsessionidfile buildSessionId --labid sl_LabId_ReplaceMe --instrumentForBrowsers --workspacepath dist --outputpath sl_dist --scm git --projectRoot /path/to/source/root
#Updating LabID for first environment (i.e. MyFirstLab)
find sl_dist -type f -name "*.js" -exec sed -i 's/sl_LabId_ReplaceMe/MyFirstLab/g' {} +
#Updating LabID for second environemnt (i.e. My-2nd-Lab)
find sl_dist -type f -name "*.js" -exec sed -i 's/sl_LabId_ReplaceMe/My-2nd-Lab/g' {} + Validating the Instrumentation and build number in the JS source from the Browser
In your browser, open the source code of your JS page: is there the Sealights' instrumentation code and the right build number at the beginning of the page ? If Yes, all is set.
