Chapter 2. Mobile Development Lifecycle Overview
“Without risk there can be no progress” –George M. Low
Our collective experiences on projects tell us that we will be learning new things and doing things in new ways as our mobile projects evolve. In this chapter, we acknowledge and address the people, processes, and tools that go into this evolution to help set the expectation of change, and encourage the calculated risks to progress our mobile apps.
Introduction
“I code, therefore, I am.” is perhaps a mantra for many of us who really enjoy building mobile or other apps. While most of us are coding for the business, the fact is that developing software for the business ends up being more than just coding. Beyond programming, which is such a personal task, we must resolve defects and test or communicate to testers about fixes; we must update our extensive task lists to project/program management; we must purposefully design and ensure others know and are following the intent; and of course, we must deliver our code into production and be open to feedback from users.
Admit it! At the end of your day or sprint you would have created or touched several other assets beyond your code. One asset example is a specification, WSDL, XML, UML, which you will likely use as IBM studies indicate that 90% of mobile apps use some kind of backend services, data, or “system of record,” which are maintained by other developers who publish those same specifications. This collection of assets, as shown in Table 2.1, follow a natural teaming lifecycle from idea to production, and this lifecycle is repeated until the app does not offer enough value to the user anymore.
Therefore, this chapter is not limited to solely the mobile app code, but it evolves the singular mobile developer into an Enterprise Mobile Development Lifecycle. As a mobile developer, you’re likely already familiar with agility, as the market suggests that nearly 100% of all mobile efforts claim to use Agile methods. In this chapter, we have applied Agile application thinking to you and your team’s evolution into an Enterprise Mobile Development Lifecycle, which in the end, we expect would show how you can grow your and your team’s capabilities to deliver better quality mobile code faster.
DevOps and Enterprise Mobile Development Lifecycle Overview
A DevOps Approach Is Core to Delivering Client Value
For organizations that are driving a MobileFirst strategy,1 it ultimately comes down to the overall mobile application experience that will determine success or failure of the Business-to-Consumer (B2C) or Business-to-Employee (B2E) effort. IBM studies reveal the following key metrics:
1 http://www.ibm.com/mobilefirst
• 80% of mobile applications are used once and then deleted.
• 90% of smartphone users keep their phones with them continuously.
• 57% of clients face challenges in delivering a quality experience and the functional capability in mobile applications.
• 50% of outsourced projects are expected to under perform.
• 85% of adults expect the mobile experience to be better than using a laptop or desktop.
• 65% of consumers would not purchase products from your company if they have an initial bad app experience (Forrester Research).
Providing an overall high-quality mobile application experience is highly dependent on a continuous software delivery approach. It is not sufficient anymore to outsource or build the mobile app once and then let it stagnate—mobile apps require not only an initial operational capability but also an ongoing, agile evolution as:
• Business needs evolve
• Competitive apps are releases
• User interface (UI) innovations occur
• The underlying platform evolves
• Other information sources become available for integration including BigData, Social Collaboration, Systems of Record, and managed application programming interfaces (APIs).
DevOps is an enterprise capability for continuous software delivery of mobile applications. To demonstrate market opportunity for DevOps, the Institute of Business Value study reveals that 86% of companies believe software delivery is important or critical, yet, only 25% leverage software deliver effectively today, and nearly 70% of those that do, outperform their competitors who do not leverage this capability. For more detail and best practices on DevOps, see Chapter 7.
Let me offer another perspective: projects can still fail even if project managers expertly manage schedules, analysts diligently capture business requirements, developers write quality code, and testers run thousands of tests. If all of this work is performed in silos, those efforts lead to failure, misunderstandings, and a lack of trust among team members. Even if you have teams that are the best in the world in their discipline, you can still fail if they are not working together and sharing information.
One Essential View of DevOps: The Mobile Developer Perspective
While delivering an overall mobile application experience goes beyond just the code construction of a mobile developer or team of mobile developers, this chapter focuses on the key aspects of delivering great code shown in Figure 2.1.
The process in this diagram is a repeatable lifecycle that allows clients to continuously deliver high-quality mobile apps and rapidly respond to feedback at the rate and pace of the agile mobile market demands. The key steps or capabilities in the lifecycle include:
• Design and Develop: Build enterprise ready applications in a cross platform way.
• Integrate: Easily link to existing data assets or cloud services.
• Instrument: Provides a way client can understand what is happening with the application from a security, usability, and quality perspective.
• Test: Verify the app to produce a great experience and deliver the required quality.
• Scan and Certify: Scan and certify against app vulnerabilities and resolve potential compliance issues.
• Deploy: Ensure that the mobile app is deployed with the right performance and scale.
• Manage: Ensure that app or device has the appropriate management and governance.
• Obtain Insight: The client can examine the user experience and be able to determine how to effect change, and then link that back into a continuous delivery cycle.
While these steps are listed in sequence, the reality of adding more capabilities to your team is that it is very similar to adding capabilities to your application: you iterate your way there and add more capabilities as you progress, evolving the team’s capabilities over the life span of the effort. History suggests that attempting to add all of these capabilities at once would be too disruptive for any team as new technologies often involve a learning curve.
The remainder of this chapter takes you through a series of suggested “sprints” of the above capabilities. Please note that this is just a suggestion based on the progression of a mobile app and your actual implementation of capabilities may be different based on your business needs and financial justification. For assistance in prioritizing capabilities and aligning them to your business value, consider a DevOps Assessment.2
2 https://www.ibm.com/developerworks/community/blogs/invisiblethread/entry/diy_with_ibm_s_self_assessment_tool_for_devops_practices?lang=en
Sprint 1: “Hello World”—Initial Operating Capability and Prototype
As organizations seek to get to market first, investments are made in small teams of “heroes” that abandon most well-defined institutional processes to build a mobile application. In some of these cases, these investments are “side-projects” or experimental prototypes to help internally “sell” the concept to established business units. Interestingly enough, when these prototypes are created with an optimized user experience, the reaction is almost always like one client’s story, “we need that app to help our mobile workforce be more productive.” The result of this “selling” now means the effort must be turned into a real project!
Design—The Big Picture
IBM Founder Thomas J Watson quoted, “Good Design is Good Business.” Developers and teams like the one mentioned above have to start somewhere, so we provide some tactical advice here, while Chapter 3 addresses this in more detail.
In this first “sprint,” we will cover some brief, but different design aspects:
• Coding the basic User Experience (UX) Design—it is where everyone starts!
• Designing and Rapid Prototyping—a continuous activity to meet evolving user need
• Leveraging Solution Design—creating or leveraging the Leveraging Service Oriented Architecture (SOA)/Web Services operational components of the environment in which the application runs
Design: Turning Your Primary User Story into a Basic UI
Whether you are building an API, a mobile app or other platform effort, your first place to deliver valuable software is to really understand what single thing you will deliver as value first to the user: this is your initial operating capability. While prioritizing the many requests and determining value itself can be a detailed line-of-business best practice, those are capabilities we can add later, leaving us to focus initially on building an interface to represent this initial value.
Most projects simply begin with the native toolkits and Software Development Kits (SDKs). Historically SDKs have instructed you to build the UI with code in a “Hello World” type of tutorial. Most often in these beginner tutorials, the goal is to help you get all of the way through to a deployment of your app, so that you can get a feel for the overall process, much like this chapter itself does!
As for the UI, with the Android SDK you build an XML code representation of your UI, which is described in the “Building a Simple User Interface” of the developer training.3 Tools in this basic UI category, however, are advancing quickly, and depending on your choice of platforms, the experience can be vastly different. For iOS developers, you incorporate your code into storyboards and scenes that you drag and drop, which is a good lead-in to the next section.
3 http://developer.android.com/training/basics/firstapp/building-ui.html
Design: UI Mock-ups and Rapid Prototyping
IBM’s Design Group4 suggests these best practices of Design Thinking. In the end, it really comes down to:
• “Look”: Visual appearance including but not limited to the UI components
• “Behavior”: Focused on the process or flow of the user interaction
While there are a number of free (e.g., http://maqetta.org) and low-cost products (e.g., http://uxpin.com/, http://balsamiq.com) in the market for building UI “mock-ups” or “wireframes,” IBM’s mobile, Eclipse-based IDE’s have a common UI builder: the Rich Page Editor. Based on a WYSIWG approach, the Rich Page Editor not only creates the UI using an easy drag and drop approach, but also provides guidance on the placement of typical UI elements (i.e., buttons), and generates the code dynamically for the interface. In fact, the Rich Page Editor supports a WYSIWG design view, source view or a split view that combines the Source and Design views in a split screen view so you can see the changes from one view reflected in the other. The Android SDK has a similar “Design/Preview” concept, for your manual XML coding (Figure 2.2).
The Rich Page Editor can be found both in the MobileFirst Platform Developer Edition5 and the Rational Application Developer (RAD) IDE.6 The choice of IDE is not mutually exclusive for enterprise applications—refer to the following articles for more information and guidance on IDE selection:
5 http://www.ibm.com/software/products/en/mobilefirstfoundation
6 http://www-03.ibm.com/software/products/en/application
• Server-side mobile application development: Part 5. Integrate the IBM MobileFirst/Worklight® adapter with EJB application7
7 https://www.ibm.com/developerworks/community/blogs/e4210f90-a515-41c9-a487-8fc7d79d7f61/entry/part_5_integrate_the_ibm_worklight_adapter_with_ejb_3_1_application?lang=en
• Take full advantage of IBM’s IDEs for end-to-end mobile development8
8 https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/2fad2df2-9c68-4aa3-abba-01e910211998/page/5531e600-93c7-46f6-86f4-a570b1bcf391/attachments
One distinct IBM advantage for this Rich Page Editor capability is this design/source view showing code as you create the interface. Many alternatives on that market that produce mock-ups, later have to be given to developers as a work product to help developers separately code the solution.
There have been integrated partner solutions for prototyping, such as iRise Connect for IBM® Rational9 that makes high-fidelity visualizations instantly accessible from within IBM tools. Through the history of application development, many advances have been made to integrate the benefits of rapid prototyping into actual reusable application components and once can expect the market to see more convergence in this area as more innovations meet standards for development.
9 http://ww2.irise.com/resources/view_video/generalVideo_28
As for the “behavior,” while often “reverse engineered” via UI construction, a common mistake is to build an interface without clearly understanding the user interaction first. Whether you use a whiteboard or a tool, we recommend a standards-based approach like UML use case or sequence diagrams, as the standard is well-defined on how we can capture and document such interactions.
Tools like Rational Software Architect (RSA)/Design Manager,10 implements UML 2 and the typical diagrams found in use case development: Use Case, Scenario, Activity diagrams, as well as “agile sketch diagram” support for more informal information capture (which can be formalized later if required). If you opt for textual user stories, you can capture these in Rational Team Concert11 as part of your sprint planning (Figure 2.3).
10 http://www-03.ibm.com/software/products/en/rational-software-architect-family
11 https://jazz.net/products/rational-team-concert/
We mention both of these early because user experience is critical and documenting this for your future team’s understanding can really improve productivity just like the IBM Interactive team benefits12 when they bring on new team members and use UML to streamline communication. Similarly, if your enterprise data and services teams have completed their SOA or other designs using RSA Design Manager, then you would be able to integrate this Solution Design information more quickly into your mobile application, which is a good place to mention this as we transition to this very topic.
12 http://www-03.ibm.com/software/businesscasestudies/no/no/corp?synkey=A951466Y90458U66
Integrate: Enterprise Services and Data
As mentioned previously, 90% of mobile applications leverage backend enterprise data and services, and therefore integration to these systems and the developers that support those systems is important to continuous software delivery. Despite this fact, in working with several clients and IBM Business Partners, we are finding that there is still a significant portion of companies that have not invested in publishing those services nor have they made a transition to SOA to make the transition to mobile easier.
If you have not yet made that transition, please refer to Chapter 5 for approaches leveraging the Enterprise Service Bus, DataPower®, CastIron®, and other mechanisms for integrating enterprise services and data.
If you have already made that transition, you may be in the position to leverage your existing Enterprise Services and Data designs, or in some cases even generate code for your mobile client based on existing RESTful services that you might have catalogued already in your enterprise design (Figure 2.4).
Test: Manual Testing Is Better than No Testing
Nearly all mobile teams use manual testing as their primary approach for verifying quality of the application. This isn’t really a surprise, as history tells us that test automation, as described in Chapter 6, doesn’t often keep up with the developer innovation, but as the market matures that will be a different story. For initial operating capability, testing is specifically aimed at verifying quality of that single piece of functionality that is providing value to the client. At this point in the cycle, there is not much else to test, manage, or provide any significant regression tests upon, so only manual testing makes sense here. The primary advice here is to not only do some manual testing, as some teams even overlook this, but also to start to get the testing organized with clarity on what to test, whether it is sharing out the single design or prototype with the people testing, or constructing some simple test procedures for the same audience.
Test: Simulate/Preview
In these early stages, developers are typically the ones also doing the testing efforts. One developer-focused manual approach to visual verification of the application is using IBM MobileFirst Platform Developer Mobile Browser Simulator. While technically not a test, the Mobile Browser simulator does give the developer a rapid application development/prototyping approach to building the UI and then reviewing the apps look and feel in a variety of different platform configurations, including a change in orientation (Figure 2.5).
Sprint 2: “Hello DevOps!”—Improve Developer Productivity
Welcome to the first chapter that really goes beyond the coding experience and looks to improve developer productivity with additional approaches and tools to help developers continuously delivery higher quality mobile applications.
Develop: Productivity with Wizards and Mobile Platform Portability
The MobileFirst Platform Developer Edition offers a more productive set of design and development features. Use wizards, visual UI editors (like the Rich Page Editor discussed previously), prepackaged UI frameworks, and JavaScript API for common UI controls. Apache Cordova is prepackaged with MobileFirst Platform.
Project creation wizard creates the initial structure for the application, including packaging structure for UI and logic components, backend adapters, and application deployment to MobileFirst Platform server. To quickly help target new mobile platforms, you can add platforms “on-the-fly” (while you continue to promote code reuse), and the MobileFirst Platform Developer Edition creates the necessary project structures for Android or iOS’ XCode automatically, streamlining your ability to build your native or hybrid application.
Instrument: Quality Assurance and Testing “In the Wild”
IBM’s Mobile Quality Assurance (MQA)13 improves application quality and the customer experience through streamlined reporting of defects, automated crash reporting, sentiment analysis, and improves turnaround time on fixes with over-the-air distribution of new builds (Figure 2.6).
13 http://www.ibm.biz/mobilequalityassurance
Defect reporting is easy with IBM MQA: simply shake the phone to initiate a bug report and a screen shot is captured along with several important pieces of information about the phone state (i.e., OS, version, manufacturer, signal strength). Typically, capturing this information and manually entering it into a tracking system may take about 10 to 15 minutes per defect and is often time-prohibitive for testers to gather all of this information to provide quality analytics to the development team. From a time savings return on investment, just 150 bug reports is one week of mobile team time saved (Figure 2.7). Once captured, crashes or bug reports can be analyzed by these characteristics, such as platform or OS version, to determine if quality issues are specific to a particular mobile environment—something that otherwise, would be very difficult to identify until it is too late and the user uninstalls the app.
To take advantage of this capability, simply instrument, add the MQA SDK calls into your mobile app per the online help instructions, and you can begin to take advantage of these time saving capabilities. These changes take less than an hour to do and you only need to do them once. Libraries exist for both preproduction testing and an even lighter weight production library can be used to deploy the app into app stores, enabling you to collect user feedback and crash reporting.
Test: Code-Centric and Unit Testing
JUnit and Selenium are two code-centric types of testing mechanisms—you must write additional test code to execute these tests. The Selenium project automates browsers, primarily for automating mobile web applications for testing purposes. Selenium has extended from mobile web apps into native and hybrid app testing with Selendroid and iOS-driver (neither as of the date of this entry have reached version 1), which uses the Android instrumentation framework, and UI Automation framework from Apple, respectively. While there is a Selenium IDE that plugs into the browser to help export recorded tests to code, the Selenium documentation states:
We don’t, however, recommend you do all your test automation using Selenium IDE. To effectively use Selenium you will need to build and run your tests using either Selenium 2 or Selenium 1 in conjunction with one of the supported programming languages.14
14 http://docs.seleniumhq.org/docs/01_introducing_selenium.jsp#choosing-your-selenium-tool
Clients who are already using this approach would find additional productivity value in these IBM tools. Each of these is described more fully in the coming sections because these may involve professional testers that do not necessarily have programming skills applicable to developer-centric testing:
• Rational Test Workbench—provides record and playback of automated tests with no coding required.
• Rational Quality Manager (RQM)—plans, designs, reviews, and executes a variety of different tests including but not limited to JUnit Selenium tests and tests created in Rational Test Workbench.
• To support DevOps Continuous Testing, most any test can be included as part of an automation workflow and further enable continuous delivery activities using IBM UrbanCode Deploy.
Deploy: Automate Your Deployment Pipeline
While “Release and Deploy” most often addresses the code release and deployment of a software solution to test and production environments, at its core, this approach is an automation step that also applies to various middleware components, such as Messaging, Enterprise Service Bus, as well as the Application Servers, where often times manual steps can be improved with automation for more reliable and consistent results.15
15 https://developer.ibm.com/urbancode/plugins/
Continuous release and deployment provides a continuous delivery pipeline that automates deployments to test and production environments. It reduces the amount of manual labor, resource wait-time, and rework by means of push-button deployments that allow higher frequency of releases, reduced errors, and end-to-end transparency for compliance. IBM’s products for Continuous Release and Deployment:
• IBM® UrbanCode Deploy16 orchestrates and automates the deployment of applications, middleware configurations, and database changes into development, test, and production environments (Figure 2.8). While UrbanCode Deploy integrates with many open source tools that are found in clients today, it also adds additional client value with integration to IBM MobileFirst Platform Developer to streamline mobile apps into deployment. Please refer to the UrbanCode Plugins page for integrations with middleware. To support DevOps Continuous Testing (testing describe in the next section), almost any test can be included as part of an automation workflow and further enable continuous delivery activities using IBM UrbanCode Deploy.
16 http://www.ibm.com/software/products/en/ucdep/
• IBM MobileFirst Platform Application Center17 securely deploys apps through a private enterprise app store (Figure 2.9). Developers can distribute mobile builds and elicit feedback from development and test team members.
17 https://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.1.0/com.ibm.worklight.getstart.doc/start/c_wl_overview.html
• IBM MQA18 provides an “over-the-air” distribution model for application updates under test, where specific versions can be selected to be deployed to select users. API-level distribution control is also provided to support continuous integration or continuous deployment activities as shown above.
18 http://www.ibm.biz/mobilequalityassurance
• IBM® UrbanCode Release19 manages the release of complex interdependent applications, infrastructure changes, and simultaneous deployments of multiple applications.
19 http://www.ibm.com/software/products/en/ucrel/
• IBM Cloud Orchestrator20 provides an open and extensible cloud management platform for managing heterogeneous hybrid environments. The software integrates provisioning, metering, usage, and accounting as well as monitoring and capacity management of cloud services.
20 www.ibm.com/software/products/en/ibm-cloud-orchestrator
Sprint 3: “Software Delivery Is a Team Sport!”
Now that we have improved individual developer productivity, let us focus on expanding our success beyond ourselves, after all, a (small) team will produce more than an individual. This is where things begin to get interesting from a changed perspective, as high-performance teaming usually follows a “forming,” “storming,” “norming,” “performing” model.21
21 Tuckman, Bruce W. 1965. Developmental sequence in small groups, Psychological Bulletin, 63, 384–399. https://en.wikipedia.org/wiki/Bruce_Tuckman
Develop: Agile Planning
Nearly all mobile development teams use Agile processes and planning. IBM DevOps Services for Bluemix and Rational Team Concert supports sprint planning and backlog management, and captures information about the work items as developers complete them (Figure 2.10).
Develop: Work Items (Defects, Enhancement Requests)
All developers fix defects and implement enhancement requests, but how developers take on these work items varies greatly from organization to organization. As software teams or departments grow, they will quickly outgrow the email and spreadsheet tactical implementations. Mostly gone are the days of home-grown defect tracking systems, as open source solutions such as Jira become more visible. But this is a market with 100’s of no/low-cost tools for the specific task of tracking some data about a task through some workflow, and implementations of data field security (who can change what data fields), and integrations also vary tremendously among the various market offerings.
IBM MQA, mentioned previously, already has integration into Rational Team Concert or IBM DevOps Services for Bluemix to streamline defect or feedback entry into your backlog.
Develop: Application Lifecycle Management (ALM) Imperatives
As you progress from developer to team productivity, you absolutely need a common vision and mission to unite the team. Teams should, therefore, discuss a set of imperatives that increase productivity through a common approach across all roles of the project.
From this reference,22
22 https://jazz.net/library/article/637
“many organizations are faced with hastened delivery schedules due to competitive pressures and the need to innovate. Yet software development is difficult, and the software systems that are maintained and delivered by the world’s IT and device development organizations are astoundingly complex. Teams challenged by reduced time to delivery must do so without increasing their budgets or sacrificing quality. Their strategy, instead, must be to improve software development efficiency. A solution to this dilemma is to improve Lifecycle Collaboration with Application Lifecycle Management.
Designed for the execution of a software delivery project, Application Lifecycle Management solutions coordinate people, processes, and tools in an iterative cycle of integrated software development activities, including planning and change management, requirements definition and management, architecture management, software configuration management, build and deployment automation, and quality management. In addition to the capabilities, the fundamental features of an ALM solution include traceability across lifecycle artifacts, process definition and enactment, and reporting.”
This same article also states that there is no “one-size fits all” solution, and for mobile there appears to be more focus on Agile/Real-time planning and these two imperatives briefly described here (for the two other imperatives, see https://jazz.net/library/article/637):
• Establish Lifecycle Traceability of Related Artifacts—developers may often state, “it would be nice if I could see all the tests associated with this defect” or “what builds are associated with a work item?” For mobile development teams, this information should be at their fingertips so that development and design analytics23 can help individuals find the information they need quickly (Figure 2.11).
23 http://www.youtube.com/watch?v=NovQGpa2H6E
• Enable In-Context Collaboration—having a single source of truth where project information resides, this imperative avoids relying on emails, chat programs, disconnected spreadsheets, and “word of mouth” as collaboration tools.
Test: Improving Manual, Automating User Interface Tests, and Test Data Management
This section is purposefully short as there is a detailed testing Chapter 6 later in the book. Teams should not overlook improving the busy “office work” that often occurs with planning and organizing manual testing efforts. While many projects strive for “100% automation,” teams rarely ever get to 85% automation. Therefore, manual testing is here to stay. RQM can execute a variety of different tests including but not limited to JUnit Selenium tests and tests created in Rational Test Workbench. Studies show that most clients are still doing a majority of their testing manually, and RQM can help automate many of the tasks of planning, designing, and executing manual tests. Furthermore, there is a mobile app for RQM24 that helps clients run manual tests (this approach is not limited to testing mobile apps).
24 https://www.youtube.com/watch?v=Tm9MEk8dZzA
Automated UI testing is often the next place mobile teams pursue, primarily because of the vast productivity gains typically associated with a “record/playback” type of approach, which can run tests more consistently and during any hour of the day to “verify quality” of your application’s UI. Rational Test Workbench provides this record and playback of automated tests with no coding required (Figure 2.12). Recording can occur on the device itself or in an emulator, and produces a human readable set of commands that you can customize through the RTW interface. This reduces the need to have developers do all of the testing and development, and can shift testing to QA professionals who may not have the development experience to use code-centric testing approaches.
As you will see later, an Eclipse environment instruments an application to the targeted device running a thin mobile client and drives the UI automation. These kinds of tests can run locally or in a device cloud, such as IBM Business Partner Keynote’s DeviceAnywhere.
Mobile teams may not have time to do manual testing with multiple data conditions and once again, automation is essential in improving the mobile application experience. IBM® InfoSphere® Optim™ Test Data Management25 optimizes and automates the test data management process. Prebuilt workflows and services on demand facilitate continuous testing and Agile software development. IBM InfoSphere Optim Test Data Management helps development and testing teams use realistic, right-sized test databases, or data warehouses to accelerate application development. InfoSphere Optim Test Data Management helps organizations:
25 http://www.ibm.com/software/products/en/infosphere-optim-test-data-management/
• Streamline test data management processes to help reduce costs and speed application delivery.
• Analyze and refresh test data on demand for developers and testers.
• Create production-like environments to shorten iterative testing cycles, support continuous testing, and accelerate time to market.
• Protect sensitive data based on business polices and help reduce risk in testing, training, and development environments.
• Use a single, scalable enterprise solution across applications, databases, and operating systems.
• Provides a comprehensive continuous testing26 solution through Rational Test Workbench27 for functional, regression, integration (service virtualization), and load testing.
26 http://www.ibm.com/ibm/devops/us/en/
27 http://www.ibm.com/software/products/us/en/rtw
Sprint 4: “Ruggedized for the App Store”
Now that you have gotten your team involved, together, you will want to “ruggedize” your mobile app for the app store, that is, you’ll want to verify quality and security concerns before you release something that may cause a negative brand impact and/or poor ratings in the public app stores. For private or enterprise-level app stores, the same applies and in fact, your organization may already have some service-level agreements in place for performance or security standards that you should meet prior to publishing to the internal app store.
Test: “FURPS” and Virtualization
When testing, there are several dimensions you should consider in this process, which are well categorized by the acronym “FURPS.” Each of these dimensions is related to the kinds of requirements that often drive acceptability of any application (see the subsequent Chapter 6 on testing for more detail):
• Functionality—verifying system functions through UI testing or protocol analysis
• Usability—verifying the user experience either manually or through UI testing
• Reliability—verifying the stability and uptime, through continuous automation testing or stress testing
• Performance—verifying the system meets performance service level agreements through scalability testing
• Supportability—representing the serviceability or maintainability of the system under test
Expanding this definition, see the Wikipedia page on FURPS and FURPS+, you might push back and consider that all of this testing will take time, leading you to the conclusion that these additions could not possibly keep you delivering software continuously! To some extent, testing and good practices are your “insurance” against some of the risk factors that arise in most software projects. Agility is important to your mobile project and testing more frequently with automation is an approach to address that risk.
Test virtualization is a technique that can boost a mobile team’s ability to test more frequently as it often takes time to set up a backend test environment, not to mention the costs usually associated with a test environment. Virtualization starts by capturing the actual traffic between the mobile app and its associated enterprise or cloud services. Once identified, then those services can be “stubbed out” of the testing and placed in virtual services that the mobile team can stand up and have complete control to execute tests to match the ongoing spring delivery schedule.
Scan and Certify
The IBM MobileFirst Reference Architecture chapter on Security states:
“Secure mobile development practices should be integrated in each stage of the software development lifecycle. Mobile application design and development should be performed with a security conscience and testing teams need to automate their security-specific unit tests early and often during the development lifecycle. This process will help avoid discovery of critical security issues later in the development process and avoid delay of the Mobile application to the market.”
To help our clients “build security in” from the early stages of development, AppScan® Source can be used to scan the source code for vulnerabilities (Figure 2.13). AppScan’s other components also help assess existing web sites and web services for vulnerabilities.
Figure 2.13 IBM Security AppScan: identify vulnerabilities in web and mobile application source code
Mobile apps may be increasingly leveraging open source software (OSS). While OSS is free, it comes with license obligations that must be met. Some clients may be interested in certifying their source code for compliance through the Ready for IBM Rational business partner solution.28
28 https://www-304.ibm.com/partnerworld/gsd/showimage.do?id=23066
Obtain Insight: Application Quality Feedback and Analytics
In both preproduction and production, developers and line of business/digital marketers can gain insight into the feedback that users and testers provide. This insight can come from a mobile app that has been instrumented with IBM’s MQA (see the Instrument section earlier in this chapter, Figure 2.14). Preliminary findings suggest that collecting private feedback while successful transactions occur during the mobile application usage may increase the public rating of an application in the app store.
Sprint 5: “Optimizing Enterprise DevOps”
As this chapter comes to a close, our last “sprint” is aimed at optimizing the approach by integrating the enterprise developers and managing the postapp store delivery customer experience and campaigns.
Integrate: Enterprise Developer Integration
Once again, as 90% of mobile applications rely on enterprise data and systems, some level of coordination should be occurring between mobile developers and enterprise developers. In addition to mobile UI developers leveraging IBM MobileFirst Platform Developer Edition, the developers working on the enterprise systems can use any of the IBM Rational IDEs to refactor or extend existing systems supporting these platforms: z™ (RDz), Power (RDPower), and WebSphere (RAD or RSA) (Figure 2.15).
Figure 2.15 IDEs are optimized for the developer on each platform supporting the mobile user experience
Developers need to coordinate work across mobile and enterprise services to ensure overall user experience system behavior. In any particular coordinated release requiring changes on mobile and enterprise systems, you will likely have:
• Work Items—to assign out, track, and manage the tasks across all the platforms involved. One common element to all of the IDEs mentioned above is that they are all Eclipse-based and plugins like Rational Team Concert can help organize the “developer inbox” across those platforms.
• Delivered Code, Integrated Code—as developers contribute, continuous integration, build support, and integration testing will be required to ensure system behavior. Rational Team Concert, which runs on multiple platforms, provides build engines to support this at not only the individual level, but at integration build time as shown in the graphic below (Figure 2.16).
• Tests That Verify the Quality—as described in the Testing chapter (Chapter 6), testing of this integration is vital and Rational Integration Tester as a part of Rational Test Workbench can verify quality of these developer changes.
Instrument and Obtain Insight: Customer Experience (CX) and Campaign Management
Developers can instrument their applications to provide a richer and better quality mobile app experience and get answers to questions like these:
• What parts of the application are users using the most (and perhaps should test the most)?
• What parts of the application are users using the least (or at all—perhaps this code can be eliminated?)?
• Are users not able to complete certain transactions?
Instrumentation involves injecting source code, using APIs from various libraries, into the application, typically manually; however, some instrumentation is automated. These instrumented points send “signal flares” to your server collecting information about your application’s usage.
TeaLeaf® uses the client experience information to analyze the customer experience from a business perspective—is the customer able to complete their transaction with minimal frustration and clicks—and application monitoring uses the client experience information to determine if any IT problems in the end-to-end application flow are negatively impacting the customer experience (Figure 2.17).
Xtify® is a mobile campaign management solution for marketers and delivers an SDK that MobileFirst Platform developers can embed in their mobile applications so that mobile marketers can target their app users. Combined with MobileFirst Platform, there are capabilities for push notification, geo-location, and more.
Obtain (App Store) Insight: Mobile Quality Assurance
While customer experience and marketing campaign management offer private experience data, app stores (Apple App Store and Google Play) offer some quality metrics that can offer insight into public user sentiment. Globally, two new reviews or ratings are entered into app store daily. This information can be harnessed without any instrumentation with MQA to review rating trends or even competitive analysis (Figures 2.18 and 2.19).
Manage: Application Versions, Updates, and More!
Now that you have deployed an app to an app store, and assuming success, you have now deployed your application to thousands (hopefully more) of devices or endpoints. While there are a multitude of considerations for the operational environment discussed in Chapter 7, you as developer have to manage your versions carefully moving forward. You have experienced that there is a built-in delay in getting apps published. There may be times when you require a critical update but cannot afford that built-in delay. If you have built a hybrid application, the MobileFirst Platform provides a “Direct Update” feature that allows you to quickly update application web resources (HTML, JavaScript, and CSS) without going through the vendor (Apple/Google) app store review process (Figure 2.20).
When you deploy the latest build without changing its version to the MobileFirst Server, the next time the app tries to access the server, it will automatically retrieve the latest web resources after prompting the user to accept the update. Direct Update cannot be used to update native code.
For those building internal enterprise applications, The MobileFirst Platform Application Center can be used as an Enterprise application store. The concept of the Application Center is similar to the concept of the Apple public App Store or the Android Market, except that it targets only private usage within a company. The Application Center manages mobile applications and you can use the Application Center as part of the development process of an application. Furthermore, the MobileFirst Application Management feature enables mobile operators and administrators to securely track, search, and control access to users through the mobile applications that are used on their devices, all from the MobileFirst Operations Console. The Mobile-First Platform has a diverse set of capabilities well-suited for taking mobile applications through the Enterprise Lifecycle (Figure 2.21).
Summary
In summary, these DevOps Enterprise Mobile Development Lifecycle suggestions are based on a combination of what is being implemented in the market today, and prioritized based on a developer-centric, incremental added value approach for the entire mobile development team. Your actual implementation of capabilities may be different based on your business needs and financial justification and again, for assistance in prioritizing capabilities and aligning them to your business value, consider a DevOps for Mobile Assessment from IBM to offer you such assistance.29
29 https://www.ibm.com/developerworks/community/blogs/invisiblethread/entry/diy_with_ibm_s_self_assessment_tool_for_devops_practices?lang=en