Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Building a scalable app factory with Appcelerator Platform

864 views

Published on

Sharing the challenged in building a Mobile Backend as a Service (MBaaS) platform for Appcelerator Alloy apps using Joomla and a whole host of development tools for a London based startup where I am CTO

Published in: Software
  • Be the first to comment

Building a scalable app factory with Appcelerator Platform

  1. 1. Angus Fox - @nuxnix CTO, Piota, @Piotasocial, http://www.piota.co.uk Director, @Multizone, http://www.multizone.co.uk Secretary, Social Developers London, @socdevlon https://uk.linkedin.com/pub/angus-fox/0/b16/457 LondonTitanium User Group 9 June 2015
  2. 2. Background Objectives Solutions Challenges Conclusions Questions / Discussion Zendesk ticket giveaway
  3. 3.  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 ▪ FirstAutomatedTest 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 governmentG-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
  4. 4.  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)
  5. 5. App Screens  Home  News  Events / Calendar  Info  Contacts  Push notification  Forms  Surveys
  6. 6.  Any item can be a push notification  Push goes via Appcelerator cloudAPI endpoint, mapped to Apple and Google push API  Custom code runs as a cron job  And, yes, it does work on an AppleWatch
  7. 7.  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
  8. 8.  Uses Joomla! Front-end  EachApp 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
  9. 9.  Use as much of the core functionality as possible  Keep the number of extensions low  Make the template adaptable and responsive
  10. 10. Paul Ryan, Angus Fox, Bronwyn Goodwin, Andy Gaskell Not as illustrated 
  11. 11. So we made Apps...lots of ‘em
  12. 12.  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
  13. 13. ● 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
  14. 14. JavaScript Calabash Xcode
  15. 15. ● 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 use o 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.
  16. 16. 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
  17. 17. ● Google PublisherAPI 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)
  18. 18. ● 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
  19. 19. ● 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
  20. 20. ● App changed to reduce static config settings with dynamic data ● Appropriate fallback to maintain user experience
  21. 21. ● Give customer facility to choose (limited) colours and icons ● Generate alloy theme on the fly and apply it at build time
  22. 22. ● 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
  23. 23.  Initially running on shared hosting, ok for 30 back-ends.  Moved to a ManagedCloud Server  New backends created from a backup seed file.  Scripted deployment
  24. 24.  A reliable and automated CI build system is very complex to create  ManyApp 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
  25. 25.  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
  26. 26. Presentations are available from Slideshare Slides http://www.slideshare.net/nuxnix Commercial Hackathon Possibly 25-26 July – London - PAID email me : angusf@piota.co.uk
  27. 27. King's Place, LONDON, UK https://www.eventbrite.co.uk/e/the-art-of-customer-satisfaction-2015-london- tickets-16893983359 Email me

×