From manual to continuous automated deployment of mobile Worklight applications

Continuous build and deploy of mobile Worklight applications with IBM UrbanCode Deploy

This article describes how to use IBM UrbanCode Deploy to define a DevOps deployment solution for IBM Worklight mobile artifacts. By defining a deployment using IBM UrbanCode Deploy with the IBM Worklight plugin, mobile teams can respond to feedback faster and have a repeatable process with reduced risk.

Share:

Joel Cayne (jcayne@ca.ibm.com), Software Developer, IBM

Photo of Joel CayneJoel is a software developer on the IBM Rational Mobile Solutions team at the IBM Canada Lab. He has previously worked on other IBM products, including IBM Rational Application Developer, and as a committer on the Eclipse Test and Performance Tools Platform (TPTP) project. Joel has a Master of Science degree from York University in Computer Science.



25 February 2014

Also available in Chinese Portuguese

Introduction

In response to customer demand for access to data from mobile devices, an increasing number of applications now include mobile components. The shift to mobile means that development teams must adapt to the unique lifecycle demands of mobile development. Teams must frequently release new versions of mobile applications in response to feedback from customers and testers, or because of changes to the back-end (for example, updates to a database or web service). To keep up with user demand, mobile development and operations teams are required to implement short development cycles. These teams turn to the DevOps practices of continuous integration and continuous delivery.

Continuous integration is the practice by which, repeatedly, developers deliver changes to a source code repository and a build system integrates the changes into the build output. Using the build output, continuous delivery deploys the artifacts to the target systems. Because continuous integration increases the number of new builds available for testing, the operations team must update the deployment environments more frequently. To help them manage the increase in demand for deployments, operations teams use continuous delivery principles.

Continuous delivery helps provide repeatable deployment processes to install and configure the new output, possibly from different build outputs, on different configurations and back-end systems, as shown in Figure 1. By using continuous delivery, code is verified sooner and code changes can be included in the build by the original developer while the ideas are still fresh in their mind.

Learn about IBM DevOps services for Bluemix, an end-to-end solution with the services you need to deliver your innovative ideas quickly.

Figure 1. Typical mobile continuous delivery topology
Overview of deployment to different environments

For most teams, continuous integration for projects is already implemented. Now teams are being asked to improve their deployment process and improve application interaction through a mobile interface. IBM® Worklight® Studio provides developers with an ideal environment to create a mobile front-end to target multiple device types through web, hybrid, hybrid mixed, or native mobile applications. IBM® UrbanCode® Deploy enables development teams to achieve continuous delivery when they deploy artifacts. With UrbanCode Deploy, the deployment process is automated. The team uses drag-and-drop process steps to graphically create sequences of actions (processes) to perform on applications and their components. The IBM Worklight plugin for IBM UrbanCode Deploy makes it possible to deploy to environments that include the IBM® Worklight® Server.

The mobile development process outlined in this article helps you take an application from development and build through to deployment on the IBM Worklight Server environment for use on a mobile device. Included with this article are sample scripts to help you to achieve continuous delivery for the mobile platform.


Mobile development process overview

At a high level, the mobile development process has the following phases, as shown in Figure 2:

  1. Develop the application.
  2. Deliver changes to the Source Code Management (SCM) system.
  3. Build the application.
  4. Deploy the artifacts created by the build.
  5. Install and use the mobile application.
Figure 2. Overview of the mobile continuous delivery process
Development process and corresponding tools

In this article, the following tools are used to implement the mobile development process:

  • To develop the application: IBM Worklight Studio 6.0.0
  • To deliver changes to the SCM: IBM® Rational Team Concert™ 4.0.3
  • To build the application: Build System Toolkit 4.0.3
  • To deploy the artifacts: IBM UrbanCode Deploy 6.0.0
  • To act as an application server: IBM® WebSphere® Application Server 8.5.5
  • To act as an enterprise server: IBM Worklight Server 6.0.0
  • To deploy to Worklight Server environments: IBM Worklight 1.0 plugin

Note: You can use other tools to implement the process. For example, you can use IBM® WebSphere® Application Server Liberty Profile instead of IBM WebSphere Application Server.

Develop and deliver the application

The development process begins when the developer creates or modifies the mobile application in IBM Worklight Studio and shares the project with the team in the Rational Team Concert SCM system.

Build the application

The project is built by the IBM® Rational® Jazz™ Build Engine, a component of the Jazz Build System Toolkit. Next, the IBM Worklight artifacts created by the build are added to CodeStation, an artifact repository that is part of IBM UrbanCode Deploy. CodeStation also tracks the versions of the artifacts and maintains a copy of the versions.

Deploy and install the application

The artifacts created by the build are deployed to the target environment automatically by IBM UrbanCode Deploy. For a hybrid mobile application, artifacts are deployed to WebSphere Application Server and IBM Worklight Server. The updated application can then be installed from the Application Center (a feature of IBM Worklight that functions like an internal app store) on the mobile device or simulator/emulator, as shown in Figure 3.

The process can be repeated when the application is updated.

Figure 3. Overview of the mobile deployment process
Detailed overview of an UrbanCode Deploy process

Click to see larger image

Figure 3. Overview of the mobile deployment process

Detailed overview of an UrbanCode Deploy process

Figure 4 shows the four phases of the mobile development process. This article demonstrates how to use the Worklight plugin to achieve the deployment phase of the life cycle.

Figure 4. Breakdown of the mobile development process
High-level overview of mobile development process

Click to see larger image

Figure 4. Breakdown of the mobile development process

High-level overview of mobile development process

Set up the continuous integration and delivery process

To set up a DevOps continuous delivery mobile application, perform the following tasks:

  1. Understand the IBM Worklight Studio development environment and artifacts.
  2. Configure the build system.
  3. Configure the IBM Worklight Server.
  4. Configure the deployment in IBM UrbanCode Deploy for continuous deployment.
  5. Use the mobile application.

With this set of tasks, you can easily modify, rebuild, and redeploy a mobile application. Use the process outlined here and the sample scripts included with this article, to customize the process to fit your scenario.

Understand the IBM Worklight Studio development environment and artifacts

This scenario explains how to develop a hybrid mobile application. With the hybrid mobile application approach, common functionality can be contained on the server so that an application can be written once for use on different native platforms.

In IBM Worklight Studio, a mobile application is created in a Worklight project, as shown in Figure 5. In this example, the project is called JKEBankMobile (annotation 1), a hybrid mobile banking application.

The project includes the following parts:

  • Two adapters (annotation 2), which define access to services, such as an adapter for connecting to charities for making donations.
  • Common hybrid application code, such as the banking login page, which is contained in the common folder (annotation 3). The common application code is deployed as the IBM Worklight application (.wlapp) to the IBM Worklight Server.
  • Operating system-specific code. The example JKEMobile application includes support for Android™ and iOS® environments (annotation 4).
Figure 5. Worklight project layout
Detailed view of Worklight project artifacts

When you build your IBM Worklight project, some or all of the following artifacts are generated:

  • The native binary file that is installed on the mobile device. This file can be uploaded to the IBM Worklight Application Center.
  • For an IBM Worklight hybrid application, a .wlapp file, which contains application metadata and resources, such as JavaScript pages. The hybrid application is installed on the IBM Worklight Console.
  • An adapter file with server-side code, such as for accessing data sources, is uploaded to the IBM Worklight Console.
  • IBM Worklight project WAR file, which contains server-specific configuration information. This file is installed on the application server.

Configure the build system

The build system handles building the IBM Worklight artifacts and other related artifacts. In this process a Rational Team Concert Apache® Ant-based build is used to build the artifacts. The build environment is configured with:

  • A build engine to builds the artifacts
  • An IBM Worklight Ant JAR file to build the Worklight artifacts
  • A native SDK to build the native application

In Rational Team Concert, you must define the following resources:

  • A build engine to build the artifacts. This example uses the Jazz Build Engine. The build engine is created to run the process on the machine identified by the engine name (for example default, which is waiting for work in the engine list of Figure 6).
  • A build definition to define properties specific to the build machine where the Jazz Build Engine runs. In Figure 6, the build definition Android build is used to build the Android mobile artifacts. The build machine requires the IBM Worklight Ant JAR file that contains the build tasks to build the artifacts. The JAR file is obtained from the IBM Worklight Server.
Figure 6. Rational Team Concert build configuration
Rational Team Concert build system configuration

This article includes sample build scripts that you can use as a template to configure your IBM Worklight mobile application build environment. You can also create your own build scripts that build the IBM Worklight artifacts. To update the sample build scripts for your scenario or create your own build scripts, use the Ant tasks shown in Listings 1, 2 and 3 to build IBM Worklight artifacts. These Ant tasks, which are included in the IBM Worklight Ant JAR file, build the hybrid application, adapter file, and Worklight project artifacts.

Listing 1. Hybrid applications using the app-builder Ant task
<app-builder
        nativeProjectPrefix="Your project name"
        applicationFolder="Path to your source"
        outputFolder="Output location"
        worklightserverhost="Worklight Server host URL"/>
Listing 2. Adapter files using the adapter-builder Ant task
<adapter-builder
    folder="Path to your source"
    destinationFolder="Output location" />
Listing 3. Worklight projects using the war-builder Ant task
<war-builder projectfolder="Path to your project"
             destinationfolder="Output location"
             warfile="Output location and file name"
             classesFolder="Compiled classes folder"/>

Next, build the native application by calling the native SDK commands. For example, call the android command for Android applications, and the xcodebuild and xcrun commands for iOS applications.

When the build completes, the artifacts are output to a build output location. For example, when using Rational Team Concert, the artifacts can be stored in the build result as seen in Figure 7. These build artifacts need to be added to IBM UrbanCode Deploy's CodeStation for deployment.

Figure 7. Build artifacts stored in a build result
Built Worklight artifacts stored in build result

Add build artifacts to CodeStation as component versions

Applications in IBM UrbanCode Deploy can represent the complete project, and a component can be used to represent a subset (for example, the mobile component of an overall banking application). Similar to source code repositories, in IBM UrbanCode Deploy, CodeStation is used to manage versions for deployment at the component level. The sample build scripts include two methods for adding artifacts to an IBM UrbanCode Deploy component version:

  • A versioned file system
  • The command line client to add artifacts to CodeStation

The versioned file system uses a directory structure on the file system to maintain versions. In this approach, the root directory for the component contains sub-directories with the version names (for example, 1.0.0 and 1.0.1, as seen in Figure 8). To create a new version, add a new directory to contain the latest build content. Name the new directory using the subsequent version (for example, name the directory 1.0.2). The new version appears in CodeStation.

To copy files to a versioned file system, use the Ant code shown in Listing 4.

Listing 4. Ant code to copy files to a versioned file system
<copy todir="Versioned file system directory">
    <fileset dir="Output location"/>
</copy>
Figure 8. Sample versioned file system in C:\mobile containing two versions, 1.0.0 and 1.0.1
Versioned file system with two versions

An alternative approach is to use the command line client (CLI) to create versions and upload files to CodeStation. CodeStation stores artifacts within IBM UrbanCode Deploy and does not require access to the file system to add version artifacts. Use the following commands:

  1. Create a new version in CodeStation using the CLI. For example:
    udclient -weburl https://localhost:8443 createVersion -component "Mobile" -name 1.0.0
  2. Add the artifacts to CodeStation using the following CLI command:
    udclient -weburl https://localhost:8443 addVersionFiles -component "Mobile" -version 1.0.0 -base C:\rootDirectory

You can also write these CLI calls in Ant. For example, to add the artifacts, use the following code shown in Listing 5.

Listing 5. Add artifacts
<exec executable="${udclientPath}/udclient"
    failonerror="false"
    resultproperty="artifact-add-result"
    output="${logLocation}">
    <arg line="-weburl urbancode-web-url -username urbancode-username 
-password urbancode-password createVersion -component component-name -name version-name" />
</exec>

Sample build scripts

The included sample Ant scripts build the four IBM Worklight artifacts (native binary, hybrid application, adapter, and Worklight project) based on the Ant tasks outlined in the Configuring your build system section. Scripts for the Android and iOS operating systems are included. To customize the build scripts for your environment and your project, refer to the comments within the build scripts for instructions.

The following two scripts for deploying to UrbanCode Deploy are provided:

build-copy.xml
Uses versioned file system to create new component versions.
build-push.xml
Uses the CLI to push to CodeStation.

In the build scripts, when the IBM Worklight artifacts are compiled, the build output is uploaded to Rational Team Concert and deployed to IBM UrbanCode. Rational Team Concert logging and output files are included to help debug and trace the builds.

Overview of the targets in the sample scripts

The Ant targets within the sample scripts provide the process to build the IBM Worklight artifacts. These scripts can be customized to add additional targets, as required, for your application.

  1. The build begins with the all target.
    <target name="all" depends="hybrid,androidNative,worklightProject,fileSystemPush" />
  2. The hybrid target is called and builds the hybrid application and adapter using the app-builder and adapter-builder tasks described in the Configuring your build system section. The adapter, hybrid application and log files from the build are uploaded to the Rational Team Concert build results.
  3. The native application is built with the mobile-specific SDK, using the androidNative target for Android in the included example.
  4. The IBM Worklight project is built in the worklightProject target using the war-builder Ant task.
  5. The build output is added as a new component version in IBM UrbanCode Deploy in the fileSystemPush target. The new component version is based on the application version.

Configure the IBM Worklight Server

The deployment environment is where the IBM Worklight Server and the required software used in the mobile application (for example, services) are installed. A typical deployment environment includes an IBM Worklight Server (with the Application Center installed), application server, and database. Note that your deployment environment can have elements that are remote. For example, the IBM Worklight Server can be on a separate machine from a REST service used in the mobile application.

For each mobile application that you build, you need to configure a console on the IBM Worklight Server. The adapter (which provides access to data sources such as web services) and hybrid application (which includes application metadata and web resources) can be deployed to the console.

To create the IBM Worklight Console:

  1. Configure the IBM Worklight database and report database, either manually or using Ant tasks.
  2. Deploy the IBM Worklight project manually or using Ant tasks.

Tip: You can run the Ant tasks from within a process in IBM UrbanCode Deploy using the Ant plugin instead of using the command line.

The sample Ant script configure-was-derby.xml provided in the IBM Worklight installation configures a Derby database and installs the application into WebSphere Application Server (the script can be found in Worklight/WorklightServer/configuration-samples). For example, use the following two steps on the command line to configure the console and output to a log file:

  1. ant –f configure-was-derby.xml –l db.txt databases
  2. ant –f configure-was-derby.xml –l was.txt install

Tip: If you deploy multiple applications, create individual consoles with their own context root and a unique ID. To accomplish this, update the properties shown in Listing 6.

Listing 6. Properties to update in the configure-was-derby.xml script install target
<configureapplicationserver shortcutsDir="${shortcuts.dir}"
                            contextroot="/${worklight.project.context}"
                            id="${worklight.project.context}">

Note: You might have to restart the application server after you create the Application Center and console.

Configure the deployment in IBM UrbanCode Deploy

You have set up the build, which added the build artifacts to a new component version in CodeStation. In Figure 9, you can see an example of two component versions in UrbanCode Deploy.

Figure 9. Component versions as seen in UrbanCode Deploy
Versions 1.0.0 and 1.0.1 of the application

Figure 10 shows the component version contents, which is the output of the build.

Figure 10. Component version artifacts
Build artifacts stored in a component version

After you add the files to a version in IBM UrbanCode Deploy, you need to define a process to deploy the IBM Worklight artifacts from the build to the IBM Worklight Server.

IBM UrbanCode Deploy maps application deployment into the application, its components, the processes for taking action, and the environment to deploy to. Figure 11 shows the relationship between the application, component, and their processes.

Figure 11. Application, components, and processes
Component and application relationship

In this example, the application JKEMobile, as shown in Figure 12 with another application Application, represents the overall bank project under development. Applications contain components, which are the parts that make up the entire banking application, such as, database, web, and mobile. This method makes it possible for the application to be broken down into consumable parts so that deployment actions can be taken at a lower level when new component versions are available.

Figure 12. List of applications
Two applications defined in UrbanCode Deploy

The JKEMobile – Android component, as shown in Figure 13, defines the mobile deployment process for the JKEMobile application.

Figure 13. List of components
Two components defined in UrbanCode Deploy

Processes are defined with steps, which are actions to take during the deployment of the component or application. The component processes define the actual work to be done using the steps in a process diagram. At the application level, processes can be used to install the various components to define an overall deployment using component processes. For example, an application process can update tables in a database, start an application server, and deploy a native mobile application to the Application Center. Figure 15 shows an example component process to deploy mobile artifacts in five steps.

For each step, you can customize the properties so that it matches your environment. For example, the properties for the Upload Application to Application Center step from the IBM Worklight plugin are shown in Figure 14 and demonstrate how attributes can be customized. In this step, you can provide IBM Worklight Server specific information, such as the context root, and the native application name, for example JKEMobile-debug.apk.

The properties in process steps can have default values. The default values are references to values that you typically define elsewhere in IBM UrbanCode Deploy, such as when you create the component or environment. For example, in Figure 14, the default value for the context is ${p:component/applicationCenterContext}, which means to use the value that was defined for applicationCenterContext in the component.

Note: You can enter a different value for the property.

Figure 14. Upload application to Application Center step properties
Sample step properties and default values

Tip: In a mobile application deployment, the artifacts that should be deployed to the servers should be added to a process in the following order:

  1. Deploy or update the IBM Worklight project.
  2. Deploy the adapter to the IBM Worklight Console.
  3. Deploy the hybrid application to the IBM Worklight Console. (This can be deployed in parallel with the adapter.)
  4. Deploy the native application to the Application Center.

Figure 15 uses the steps provided in the IBM Worklight plugin, in addition to the application server plugins (for example, the WebSphere Application Server plugin), to deploy mobile application artifacts on the IBM Worklight Server. These are the actions taken in the component process:

  1. The Download Artifacts step retrieves the component version artifacts from UrbanCode Deploy to the agent machine for use with the remaining process steps.
  2. The IBM Worklight project web archive is updated on the application server using the Install or Update Application step from the WebSphere plugin. This step makes it possible for any configuration settings to be updated.
  3. Two steps are run in parallel from the IBM Worklight plugin: Deploy Adapter to Worklight Server and Deploy Hybrid Application to IBM Worklight Server. The artifacts uploaded by these steps provide the server-side resources for the mobile application.
  4. After the two steps are finished successfully, the native application is uploaded to the Application Center using the Upload Application to Application Center step from the IBM Worklight plugin.
Figure 15. Sample component process for deploying the IBM Worklight artifacts
Sample complete Worklight deploy process

When the deployment is finished successfully, you can install onto a device from the Application Center for verification. You can build and redeploy to IBM Worklight Server any further updates to the mobile application by using the same deployment process.

Tip: An environment defines the resources that are used for the deployment and is where the process is to be run. In IBM UrbanCode Deploy, you can define multiple deployment environments, such as development (Dev) and quality assurance (QA), as seen in Figure 16, where the same process can be customized to deploy to different configurations.

Figure 16. List of environments
Two application environments, Dev and QA

After you run the deployment process, the artifacts are available in the Application Center, as shown in Figure 17. In the example, the same mobile application is deployed but it targets different native device environments (iOS and Android).

Figure 17. Sample applications in the Application Center
Application Center with two native applications

Click to see larger image

Figure 17. Sample applications in the Application Center

Application Center with two native applications

Figure 18 shows an IBM Worklight Console with the JKEMobile hybrid application installed, and the application's two adapters: JKEAdapter and JKELegacyAdapter.

Figure 18. Sample Worklight adapters and Worklight application in a console
Worklight Console with adapters and application

Click to see larger image

Figure 18. Sample Worklight adapters and Worklight application in a console

Worklight Console with adapters and application

Expand on the sample

You can expand upon the sample build scripts provided with this article to deploy to multiple environments. For example, if the IBM Worklight project targets both Android and iOS, you can:

  1. Combine the build script targets for building the native applications into one build file.
  2. Add an additional step to the component process, as shown in Figure 15, to upload both native applications to the Application Center.

The steps provided by the IBM Worklight plugin provides you with the flexibility to create a process that fits your mobile application. For example, if your application includes multiple adapters, multiple adapter deployment steps can be included in the process. As seen in Figure 15, steps provided by the IBM Worklight plugin provide flexibility for you to customize processes to deploy multiple mobile applications to the same or different IBM Worklight Server. Deployment to the same server is aided by default values that can be set at the component level. For example, in Figure 14, the File property can use the application property set at the component level. In the Android component, the application component property can point to JKEMobile-debug.apk, and in an iOS component the application component property can be set to the iOS application archive (.ipa) artifact.

In addition to the process to deploy mobile artifacts, deployment processes can be added for other business processes in the enterprise, such as web, database, and so on.

Note:
As outlined in the Mobile development process overview section, this article is written towards using the Worklight 1.0 plug-in with a Worklight Server 6.0.0. For details on using newer versions of the plug-in with newer Worklight Server versions, please use this article in conjunction with the documentation included with the corresponding Worklight plug-in.


Summary

Development teams are looking for ways to respond to feedback faster. Continuous integration helps reduce the time required to build application artifacts. Combined with continuous deployment through DevOps using IBM UrbanCode Deploy, deployment time can be reduced by providing repeatable processes for deploying the build artifacts. Because mobile development teams typically have short development cycles, the IBM Worklight plugin can help to create a repeatable process to deploy mobile application artifacts to the IBM Worklight Server. The plugin makes it possible for DevOps teams to respond to feedback sooner and easily update deployment processes. The information provided in this article explains the steps you can apply to use IBM UrbanCode Deploy with the IBM Worklight plugin to deploy to the IBM Worklight Server.

Acknowledgements

I would like to thank Derek Baron, Jinzi Huang, Mike Melick, Chris Jeffs, and everyone else who has helped contribute their input, reviews, and time into the creation of this article.


Download

DescriptionNameSize
Sample build scripts for this articleSampleBuildScripts.zip16KB

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational, Mobile development
ArticleID=963606
ArticleTitle=From manual to continuous automated deployment of mobile Worklight applications
publish-date=02252014