Additional admin best practices
This sections outlines best practices for lab maintenance operations, monitoring, upgrades and packaging services.
Mobile lab inspection
Due to the nature of the setup, you must periodically perform a physical inspection of the mobile lab. The purpose of the inspection is to review the current setup, and to check for damage that may impact the system.
The following should be inspected:
Check that all devices are connected to Wi-Fi
Check each physical device for a swollen battery (When lithium-ion batteries are overheated, over-charged, or simply reach an old age, the inner cells of the battery may emit a flammable electrolyte mixture, causing the battery to swell.)
Check that all devices are charging and that the battery level is 100%.
Check that device brightness is set to minimum.
Check that the devices are not locked.
PostgreSQL, like any database software, requires certain tasks to be performed regularly to achieve optimum performance.
The following procedures are the most common:
Creation of backup copies of the data on a regular schedule
Periodic "vacuuming" of the database
For more information on database maintenance, see the PostgreSQL documentation
Logs and TMP cleanup
Even though the Digital Lab logs remove older data, some conditions cause certain log files to grow significantly. For example, the application packager log, Digital Lab audit.log, and database audit log.
You need to monitor the size of these logs and periodically perform cleanups.
Like any other production system, Digital Lab deployment requires monitoring for performance and availability.
The following types of monitoring are necessary:
Monitoring log files for exceptions and errors
Digital Lab provides various methods for effective monitoring:
REST API reference for Digital Lab: Any action related to Digital Lab can be executed via REST API. REST API calls can be used in a script for monitoring purposes.
Embedded statistics reporting engine. The Digital Lab Server aggregates statistics from the connector and exposes them via Prometheus reporter.
Digital Lab Log files are stored in the /log folder.
Because of the system’s vital business value, the upgrade process must be rolled out in an organized and robust way.
Be sure to follow these best practices:
Never upgrade in place. Use two environments – your current system and another, new installation running in parallel. Follow the procedure in Migrate the Digital Lab server .
Backup. Backup regularly, not only before an upgrade. Digital Lab does not store transactional data in the database, but it is still good practice to keep your data safe.
Compatibility check. Allow end users to rerun their tests and actions with a new system, to assure compatibility of their assets with the new version, before going live.
Leverage tools provided by the vendor. Do not try to modify the system manually. Use a migration tool for mobile applications, for example.
Plan the migration and execution. Plan your actions before, during, and after the upgrade.
For full details, see the Best practices for upgrades.
Digital Lab works with both packaged and non-packaged mobile apps. Packaging is an instrumentation method that injects the Digital Lab intercept library into the application bundle and re-signs the app with proper credentials. The advantage of using packaged apps is to provide better object recognition for record/replay as well as additional sensors simulations (such as photo or fingerprint).
After you upload an app to Digital Lab, the server automatically attempts to package the app. This gives users the option of selecting either a packaged app or the original version when running a test. To enable the functionality of automatic app packaging and signing by Digital Lab, the administrator needs to set up the packaging and signing services.
The packaging service is also used during the upgrade process when the current app is upgraded with the latest version of the instrumentation library.
For general information about packaging services, including the manual procedure for packaging the apps, see App packaging and signing services.
By default, the Android packaging service is installed together with Digital Lab Server. It does not require any special configuration, but it can impact the overall performance of the Digital Lab Server machine because the packaging service is a Java process that runs on the server.
The packaging procedure for iOS apps is slightly different.
iOS applications and agents can be signed/packaged using the embedded packaging service or a remote packaging service. The maximum number of supported device types for an individual Apple Developer account is 100 iPhones and 100 iPads. If you need to sign more devices, an additional Apple Developer account is required. To use more than one Apple Developer account for packaging, the remote packaging service is required. For further information, see iOS signing service