Wednesday, 12. September 2018 11:15 - 11:45 (30 min)
Are you into test automation or fully automated cloud deployments? A typical problem you face is determining when an OSGi system you started is fully up so the tests can do their work or when an upgraded instance is ready for production traffic again. If your system does not come up then you want to quickly spot what is wrong or missing.
The open source System Readiness framework allows to easily answer these questions. It works for any OSGi based system but also has some extensions for Sling and AEM. The built-in basic checks include that all bundles are started and a configured list of top level services are up. Custom checks in Sling and Adobe AEM include that the Oak initial indexing of an unpacked repository has finished or that the integration and content sync with an external service has finished.
The main service, the monitor, aggregates all the custom readiness checks and exposes a global readiness status as OSGi service and through a configurable servlet. It also provides root cause analysis for declarative services components. For example, the reason for a top level service not being available can be a missing config on a low level component.
Use cases range from fast pax exam based integration tests, functional automated tests on external instances, to signaling to container tools like Containerpilot and Consul that a system is ready for prime time.
Andrei Dulvac, Adobe
Christian Schneider, Adobe
In our engineering CI/CD pipeline in AEM, we install AEM instances more than 2000 times a day. In pure OSGi, there is no global “ready” status, but for an application built on top like Sling and AEM, a reliable mechanism that waits for an instance to be ready before continuing with the automation is critical. Internally, for years, we’ve successfully used tooling in the AEM launcher and automation clients to achieve this.
As Sling and AEM launchers are being re-thought and we’re now talking more and more about the feature model launcher and Sling in containers, we’ve moved our logic to the OSGi level.
We’ve also made our tooling highly customizable and empowered the owner of a deployment to write and configure the necessary readiness checks. Additionally, the whole mechanism is now open-source!