How to move your applications

Moving applications from one server to another

The package command can be used to help move your applications. package produces a ZIP file of the application directory, which can then be transferred and unzipped onto another server.

1. Start by invoking zero package in the application's home directory. For example, to package application myapp located at C:\zeroapps\myapp, change directory to C:\zeroapps\myapp then invoke zero package.
2. Transfer the generated ZIP file to the other server. (Console output from zero package includes a pointer to the generated file, which will be located in the application's export directory.)
3. Extract the ZIP file on the other server. Note that the ZIP file includes the application directory. For example, extracting the ZIP file into D:\other\zeroapps yields the new application home directory at D:\other\zeroapps\myapp.
4. Resolve the application by invoking zero resolve from the application's home directory. Even if versions don't change, this step is required to fix the paths to modules in the local repository.

Switching applications to the stable module group

A module group is a local repository of modules, typically retrieved from remote repositories. An application must be resolved against one module group. IBM® WebSphere® sMash defines two module groups to isolate released code (stable module group) from the latest code (experimental). The experimental module group may also include trial modules, which provide interesting functionality for early community feedback but not yet planned for a release.

Although it is possible to switch an application from one module group to another, switching is not intended to be a common operation. Most developers will use the free WebSphere sMash DE download, which provides tooling support and a stable runtime for testing and running applications. The resultant applications may be deployed without change to the WebSphere sMash supported runtime.

The one scenario where you might need to switch module groups would be to convert an experimental application that started out as a trial exercise and developed into a significant component that you'd now like to deploy. You can use the zero switch command to switch the module group, but additional testing is required to ensure that the application runs correctly with the new module group.

The remainder of this section describes usage of the switch command and pointers to help manage that change.

1. Install either WebSphere sMash DE or the WebSphere sMash command-line interface (CLI) using the installer (available from IBM).
2. Invoke zero switch stable in the root directory of the application to be switched. For example, to switch application myapp located at C:\zeroapps\myapp, change directory to C:\zeroapps\myapp then invoke zero switch stable .

Evaluating the success/failure of the migration

Migration should be treated like any other change in software development.

Successful migration means that the application runs correctly with the new dependencies. Before you can claim success, you must complete the migration steps, then perform adequate testing within the new run-time environment.

The following pointers might help you along the way.

Interpreting console output from the switch command

The switch command performs the equivalent of an update command after changing the module group. This will succeed as long as the dependencies can be satisfied from the new module group. If those dependencies are already available in the local repository, then the console output will be simple, such as:

switch can also succeed by retrieving missing dependencies from the remote repository. The corresponding console output describes the operation, such as:

switch fails if it's unable to obtain the dependencies. One cause of failure would be if the application used a not-yet-released module from the experimental module group. The console output indicates the problem and cancels the switch operation, such as: