This practice explores the deployment of IBM® Worklight artifacts
during development with the IBM Mobile
Development Lifecycle Solution, considering the types of testing performed
in various development stages.
Deployment of IBM Worklight Applications
Deploying a IBM Worklight application involves the following
tasks:
- The client-side web artifacts get packaged into .wlapp archives
and deployed to the IBM Worklight server.
- The server-side adapter code gets packaged into .adapter archives
and also deployed to the IBM Worklight server,
- The full client-side application code gets packaged into its native
format (device binaries) specific to the target mobile platform. It
can be installed in the emulator or physical device for testing, or
deployed to the Application Center for Quality Assurance or internal
beta programs.
- Once they are ready for production, the device binaries are eventually
submitted to any of the following:
- A public AppStore, if they are public-facing Apps.
- A corporate, private AppStore.
- A Mobile Device Management system, if they are employee-facing
Apps.
The following figure shows the basic deployment process and related
artifacts.

This practice focuses on the deployment techniques that are used
during development. For production deployment see the IBM Worklight documentation.
Additional information may be provided by mobile platform vendors.
Testing scenarios and recommended deployment techniques
During development of a IBM Worklight application, the
team moves through various types of testing scenarios that are based
on roles (who is doing the tests) and goals (what is being tested).
For instance, a developer writing JavaScript to
handle page transitions based on user interaction uses a different
testing and debugging environment than a QA person who is testing
the entire screen flow and the user experience. The main concern of
the developer is the speed of the cycle between making code changes
and seeing them take effect. The main concern of the QA tester is
to closely test the experience of a real user. As such, the developer
benefits the most from a browser-based simulation environment, backed
by a light-weight server, whereas the QA person must test on real
devices.