Download - Class.mobilefirstfoundation.chapter.2.devops
##mobile DevOps is highly complicated; it permutes by3 x client pattern (ios-native; android-native; hybrid)4 x server (jee; .js; php; MBaaS)4 x stage (dev; sit; uat; prod)2 x build variants (debug; release)Number of organization (in-house; contractor)Number of appsNumber of parallel release
Java backend
Load Balancer
Backend 1 Backend 2
RDMS
Web Server
App
https
https
Corporate LAN
Corporate DMZ
.JSbackend
Load Balancer
Backend 1 Backend 2
NoSQL
Web Server
App
https
https
Corporate LAN
Corporate DMZ
Typical Scenario:Supplier-A Supplier-B
Supplier-A Supplier-B
Pattern: native
Compute: Java
DB: RDBMS
Backend: DIY
Integration: SOAP
Hosting on-prem
Pattern: hybrid
Compute: .JS
DB: NoSQL
Backend: 3rd library
Integration: REST
Hosting on-cloud
Mixed implementation is difficult, in term of skills, and manpower
Conventional J2EE Server mobile backend/MBaaS
Hybrid/SPA/Container app Low-speed; Hi-speed
Hi-speed; Hi-speed
Native mobile app Low-speed; Low-speed
Hi-speed; Low-speed
##cycle-time of mobile delivery-cycle-time differs by technology stacks-loosely couple distributed architecture is essential implement two-speed delivery system
##use controlled mobile-backend-mobile backend provides SDK & API-loosely couple distributed architecture
JSON
mobile backend
ERPEngine
App DB
Windows Android BlackberryApple
Windows Android BlackberryApple
soap
http (rest, json) push, sms, object store
##use controlled restful api-well-structured /resilient /versioned /authenticated /secure /auditable API management
##consider mixed use of nosql & RDBMS & object-storage-are your datastore mobile-friendly-choose between System-of-records and System-of-engagements-Mixed use of Nosql & RDBMS & object store
data requirement NoSQL RDBMS object storage
Elastic Scalability Easy Hard Easy
Multi-structured data Easy Hard Easy
Multi-data center Easy Hard Easy
Data mobility Easy Hard Easy
##use mobile-first responsive design-@dev-controlled JavaScript file run at app startup determines which skin to load; reducing number of main streams
##use differential direct-update pattern1.Web resources packaged with app to ensure initial offline availability2.Web resources transferred to app's cache storage3.App checks for updates on startup and foreground events4.Updated web resources downloaded, with user confirmation or silently
Mobile backendServer
Shell
Pre-packaged resourcesPre-packaged resources
1 Download
Update web resource
App Store
Web ResourcesWeb Resources
Cached resourcesCached resources
Transfer
Check for updates
2
3
4
##mobile backend reduces the backend development, and reduces the dependency. Two options:-(on-premise) mobile enterprise app development platform, e.g. MobileFirst Foundation Platform-(cloud-based) mobile-backend-as-a-service, e.g. Bluemix
##continuous delivery pipeline—code enters at one end; and moves through the pipeline, across stages.—repeatable process to taking code changes, testing them and deploying good changes into production or staging environments.
WeeklyWeeklyHourlyHourly DailyDaily
##parallel pipelines to handle different cycle-times—mobile-backend: fastest cycle—mobile-frontend: medium cycle—conventional app: slowest cycle
##on-premise multi-stage delivery pipeline—establishment of (automated) delivery stages, with continuous integration; for both server & client—centralize build system, with builder, dependency & package manager
##software configuration management—common team repository, with version control for all artifacts —(not just code…...it should include deployment script, build script, and test script, manifests, provisioning profiles, certificates and API keys, etc.)
##build stage—centralize build and integration server; especially when there is team of teams—maintain separate build and integration areas for each SDK version supported—each team has private build & integration build—implement build variant, if necessary (ProdDebug, ProdRelease, StagingDebug, StagingRelease)
##deploy stage—install MobileFirst server; with versioned component .app & .adapter; app & environment property
##advanced deploy stages—pipeline complexity increases, by multi-stage; by multi-releases; by multi-apps; multi-teams; multi-platforms; build-variants; by client/server
V1 at UAT V1 at PROD
V2 at UAT V2 at PROD
##use private app store, for pre-production stages-deploy apps across @dev & @tester-divide into dev, test, prod stages