From manual to continuous automated deployment of IBM MobileFirst mobile applications

Continuous build and deploy of IBM MobileFirst applications using IBM UrbanCode Deploy

This article describes how to use IBM UrbanCode Deploy to define a DevOps deployment solution for IBM MobileFirst Platform Foundation (formerly Worklight) mobile artifacts. By defining a deployment using UrbanCode Deploy with the IBM MobileFirst Platform 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.



May 2015 (First published 25 February 2014)

Also available in Chinese Portuguese

IBM Worklight is now named IBM MobileFirst Platform Foundation. Please visit the IBM MobileFirst Foundation website to learn more about the components.

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 MobileFirst 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 MobileFirst Platform plugin for UrbanCode Deploy makes it possible to deploy to environments that include the IBM MobileFirst Server.

The mobile development process outlined in this article helps you take an application from development and build through to deployment on the IBM MobileFirst 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 MobileFirst 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: 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 MobileFirst Server 6.0.0
  • To deploy to MobileFirst Server environments: IBM MobileFirst 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 MobileFirst 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 MobileFirst artifacts created by the build are added to CodeStation, an artifact repository that is part of 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 UrbanCode Deploy. For a hybrid mobile application, artifacts are deployed to WebSphere Application Server and IBM MobileFirst Server. The updated application can then be installed from the MobileFirst Application Center (a feature of MobileFirst 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

Figure 4 shows the four phases of the mobile development process. This article demonstrates how to use the MobileFirst 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

Set up the continuous integration and delivery process

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

  1. Understand the MobileFirst Studio development environment and artifacts.
  2. Configure the build system.
  3. Configure the MobileFirst Server.
  4. Configure the deployment in 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 MobileFirst 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 MobileFirst Studio, a mobile application is created in a MobileFirst 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 MobileFirst application (.wlapp) to the MobileFirst Server.
  • Operating system-specific code. The example JKEMobile application includes support for Android™ and iOS® environments (annotation 4).
Figure 5. MobileFirst project layout
Detailed view of MobileFirst project artifacts

When you build your MobileFirst 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 MobileFirst Application Center.
  • For a MobileFirst hybrid application, a .wlapp file, which contains application metadata and resources, such as JavaScript pages. The hybrid application is installed on the MobileFirst Console.
  • An adapter file with server-side code, such as for accessing data sources, is uploaded to the MobileFirst Console.
  • MobileFirst 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 MobileFirst 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
  • A MobileFirst Ant JAR file to build the MobileFirst 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 MobileFirst Ant JAR file that contains the build tasks to build the artifacts. The JAR file is obtained from the MobileFirst 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 MobileFirst mobile application build environment. You can also create your own build scripts that build the MobileFirst 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 MobileFirst artifacts. These Ant tasks, which are included in the MobileFirst Ant JAR file, build the hybrid application, adapter file, and MobileFirst 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="MobileFirst 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. MobileFirst 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 UrbanCode Deploy's CodeStation for deployment.

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

Add build artifacts to CodeStation as component versions

Applications in 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 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 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 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 MobileFirst artifacts (native binary, hybrid application, adapter, and MobileFirst 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 MobileFirst artifacts are compiled, the build output is uploaded to Rational Team Concert and deployed to 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 MobileFirst 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 MobileFirst 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 UrbanCode Deploy in the fileSystemPush target. The new component version is based on the application version.

Configure the MobileFirst Server

The deployment environment is where the MobileFirst Server and the required software used in the mobile application (for example, services) are installed. A typical deployment environment includes an MobileFirst Server (with the Application Center installed), application server, and database. Note that your deployment environment can have elements that are remote. For example, the MobileFirst 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 MobileFirst 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 MobileFirst Console:

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

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

The sample Ant script configure-was-derby.xml provided in the MobileFirst 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 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 UrbanCode Deploy, you need to define a process to deploy the MobileFirst artifacts from the build to the MobileFirst Server.

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. A template is also provided at the component level, the "Mobile" component in Figure 13, for those who want to create their own application or have an existing application. The template creates a mobile component and MobileFirst deployment process.

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 MobileFirst plugin are shown in Figure 14 and demonstrate how attributes can be customized. In this step, you can provide MobileFirst 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 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 MobileFirst project.
  2. Deploy the adapter to the MobileFirst Console.
  3. Deploy the hybrid application to the MobileFirst 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 MobileFirst plugin, in addition to the application server plugins (for example, the WebSphere Application Server plugin), to deploy mobile application artifacts on the MobileFirst 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 MobileFirst 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 MobileFirst plugin: Deploy Adapter to MobileFirst Server and Deploy Hybrid Application to MobileFirst 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 MobileFirst plugin.
Figure 15. Sample component process for deploying the MobileFirst artifacts
Sample complete MobileFirst 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 MobileFirst 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 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 a MobileFirst Console with the JKEMobile hybrid application installed, and the application's two adapters: JKEAdapter and JKELegacyAdapter.

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

Click to see larger image

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

MobileFirst 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 MobileFirst 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 MobileFirst Platform 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 MobileFirst plugin provide flexibility for you to customize processes to deploy multiple mobile applications to the same or different MobileFirst 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 MobileFirst 1.0 plug-in with a MobileFirst Server 6.0.0. For details on using newer versions of the plug-in with newer MobileFirst Server versions, please use this article in conjunction with the documentation included with the corresponding MobileFirst 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 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 MobileFirst plugin can help to create a repeatable process to deploy mobile application artifacts to the MobileFirst 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 UrbanCode Deploy with the MobileFirst plugin to deploy to the MobileFirst 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 IBM MobileFirst mobile applications
publish-date=05252015