Building a scalable app factorySlides – http://www.slideshare.net/nuxnix

Slide credits to Paul Ryan and Andy Gaskell

Angus Fox - @nuxnixCTO, Piota, @Piotasocial, http://www.piota.co.ukDirector, @Multizone, http://www.multizone.co.ukSecretary, Social Developers London, @socdevlon

https://uk.linkedin.com/pub/angus-fox/0/b16/457

London Titanium User Group9 June 2015

Topics

Background Objectives Solutions Challenges

Conclusions

Questions / Discussion

Zendesk ticket

giveaway

Background

Multizone is an award winning software company providing CTO-to-go and mobile app development services for startups and

enterprises working in mobile, social, collaboration and eDiscovery Product management using talented community specialists for

development▪ First Automated Test system for native phone apps 2004, Symbian) ▪ Our first Mobile Back End as a Service (MBaaS) built in 2008 on Appcelerator▪ First MBaaS on the UK government G-Cloud supplier list

Piota, is a privately funded early stage startup based in London. Idea genesis in 2014 Piota required native mobile apps for the Education sector. Need to scale to support thousands of individually branded mobile

apps each supporting hundreds of users First app published December 2014 to App Store and Google Play Three dozen now in the stores, not all production yet

Project anatomy

The best is the enemy of the good

App has to be better than good

Don’t build an app that loads foreign content like HTML or PDF

Don’t build a web site on a phone

Do make it disruptive Do get the right team Do build the right

features (that’s the art of product management bit)

App Screens

Home News Events / Calendar Info Contacts Push notification Forms Surveys

Push notifications

Any item can be a push notification

Push goes via Appcelerator cloud API endpoint, mapped to Apple and Google push API

Custom code runs as a

cron job And, yes, it does work

on an Apple Watch

Why Joomla?... Stable & Secure Mobile Friendly Great to develop on All the good stuff there... OO & MVC jQuery Bootstrap Huge time-saver compared to writing from

scratch, provides many required features out-of-the-box

Back end is a Front End Sort of

Uses Joomla! Front-end Each App back-end has a separate

Joomla! install One custom template, branded per

App Visually customised to match look &

feel Extension for structured data -

FieldsAttatch Extension for json RESTful API -

jBackend Load of other glue we wrote

Joomla Approach

Use as much of the core functionality as possible

Keep the number of extensions low

Make the template adaptable and responsive

Dev Team

Paul Ryan, Angus Fox, Bronwyn Goodwin, Andy GaskellNot as illustrated

So we made Apps...lots of ‘em

Experienced team, agile process Founder, Intensely involved

in school governance, Likes Apps, Wants to build a business

CTO, 30 years in Product management at Oracle, Microsoft, HP, Startups

App Dev: General + UI + Web

App Dev: General + CI/CD Delivery

Web Dev: PHP, JavaScipt, CSS etc

Sales and Marketing Director: Experienced in education apps

All remote Assembla + Skype,

little or no email Weekly conf call –

ticket review Monthly meetings 2 week development

cycles, mostly Front end and back-end

working closely agile but not Agile Auto prioritisation of

the work – no surprises

Objectives● simplify development processes for adding new

schools via task automation● daily builds of app using Continuous Integration

(CI)● automate workflow of app release to beta testers

(cross platform)● automate workflow for all provisioning steps,

including push notification on ACS● change app structure to use dynamic data rather

than static configuration● provide a customer sign up and configuration

process

Solutions

JavaScript Calabash

Xcode

Simplify Development Process

● App uses single code base with multiple themes

● Grunt task runner loads correct tiapp.xml and config.json

● tiapp.xml node package used to inject common values

● Grunt tasks use same convention to aid ease of useo grunt build:school:android, o grunt build:school:ios, o grunt build:school o grunt build

o grunt test:school:android, o grunt test:school:ios o etc.

Continuous Integration (CI)

Assembla is used as Source Code Repo and Project Collaboration Tool

Go Server used as CI server

Merge/Pull request approvals in assembla trigger builds on the go server

Release to Beta Testers (Android)

● Google Publisher API used to deliver .apk updates, screenshots and meta data updates.

● Screenshot production automated with Grunt.

● Release to beta track on playstore● Google Plus community used for

alpha members (invite only)

Release to Beta Testers (iOS)

● fastlane tools used for iTunes Connect (ITC) automation https://fastlane.tools/

● provisioning profiles created/updated on the fly using fastlane/sigh

● screenshots created using fastlane/screenshots and instruments

● updates can optionally to testflight release

Example of the Moving goalposts for automation #WWDC15

Automate ACS provisioning

● cloud enable new ti apps from command line

● fastlane/pem used to automate push notification certificate creation

● phantomjs/casperjs used to add push certificates to app on ACS

App Changes

● App changed to reduce static config settings with dynamic data

● Appropriate fallback to maintain user experience

Customer Sign Up

● Give customer facility to choose (limited) colours and icons

● Generate alloy theme on the fly and apply it at build time

Challenges

● Apple and Google regulations for what can and cannot be automated

● Testflight switch off / Testflight on iTunes Connect (ITC)

● Appcelerator 4.0 / Platform changes● Maturity of third party solutions● Target environments not static

DevOps

Initially running on shared hosting, ok for 30 back-ends.

Moved to a Managed Cloud Server New backends created from a

backup seed file. Scripted deployment

Conclusions / Lessons A reliable and automated CI build

system is very complex to create Many App submission related tasks

are not easily automated iTunes submissions still get rejected

for random reasons Android fragmentation is not really

an issue App stores don’t really want you to

automate

Lessons Develop with the future in mind Try not to accumulate technical debt App developers are not back end

developers Ci / Cd is a specialism Users are typically quite non-technical, so

keep UI simple - things need to “just work” Write a good base API and evolve it APIs are just awesome “Shell” scripting in JavaScript / Node.js is

quite nice actually

Thank you, Questions / DiscussionPresentations are available from Slideshare

Slides

http://www.slideshare.net/nuxnixCommercial Hackathon

Possibly 25-26 July – London - PAID

email me : angusf@piota.co.uk

10 Free Tickets to The Art of Customer Satisfaction - London!King's Place, LONDON, UK

https://www.eventbrite.co.uk/e/the-art-of-customer-satisfaction-2015-london-tickets-16893983359

Email me