MAD FOR MOBILE John Frizelle Philip Hayes Cian Clarke #redhat #rhsummit 1
MAD FOR MOBILEJohn Frizelle
Philip Hayes
Cian Clarke
#redhat #rhsummit
1
THE MOBILEC E N T E R O F E X C E L L E N C E
APPS DON'T NEED TO
Cost $100kTake 6 months to developLive for decadesBe big monoliths on the client side
2
THE MOBILEC E N T E R O F E X C E L L E N C E
WHY YOU NEED ONE
In-house skills for an important delivery channelNot Corporate IT => Fast IT
MOBILE IS DIFFERENT
Lots of small apps, fast update cyclesOffline support means backends can fail - records still existon mobile deviceMove fast & break stuff
3
REINVENT THE RULES
AGILE DEVOPS MICROSERVICES
4
MICROSERVICESDEVOPS
AGILE
5 . 1
THREE SIMPLE TRUTHSO F S O F T WA R E D E V E L O P M E N T
1. It is impossible to gather all the requirementsat the beginning of a project.
2. Whatever requirements you do gather areguaranteed to change.
3. There will always be more to do than time andmoney will allow.
5 . 2
WHAT IS AGILE?
A time boxed, iterative approach to softwaredelivery that builds software incrementallyfrom the start of the project, instead of trying todeliver it all at once near the end.
Break projects down into little bits of userfunctionality called user stories, prioritizingthem, and then continuously delivering themin short two week cycles called iterations.
5 . 3
WHAT IS AGILE?
5 . 4
HOW DOES IT WORK?
Make a list
Size things up
Set some priorities
Start Executing
Update the plan as you go
5 . 5
HOW IS IT DIFFERENT?
Analysis, design, coding, and testing arecontinuous activitiesDevelopment is iterativePlanning is adaptiveRoles BlurScope can (and will) varyRequirements can (and will) changeWorking software is the primary measure ofsuccess
5 . 6
HOW IS IT DIFFERENT?
5 . 7
AGILE VS WATERFALL
Waterfall Agile
Quality Poor - testing at theend
Good - testing fromday one
Visibility Poor - have to waituntil the end
Good - ship fullfeatures incrementally
Risk High - schedule,technical, product
Low - early & iterativefeedback
Change Poor - stick to theplan
Good - welcome &adapt to change
5 . 8
HOW IS IT DIFFERENT?
5 . 9
BACKLOG PRIORTISATION
Backlog = All remaining work
Frequent & Small reviews
Managed by Product Owner
Constant refinement - break down stories
Look 3 to 5 sprints out
5 . 10
USER STORIES
High level features or requirements
Just enough to start a conversation
Stories can split or join
No more than a few days work each
5 . 11
ESTIMATION
Don't use days - itnever works
Relative sizing basedon complexity
Agree what a 1, 2, 5point story is
Use Planning Pokerto avoid consensusbios
5 . 12
PLANNING
Velocity = speed from story to product
#Iterations = total effort / velocity
Ongoing & adaptive
Use Burndown Charts
5 . 13
PLANNING
5 . 14
ITERATIONS
Time Boxed - Usually 2 weeks
Take highest priority stories from Backlog
Produce a shippable increment
Past performance is a guide to futureperformance
5 . 15
ITERATIONS
5 . 16
AGILE MANIFESTOHTTP://AGILEMANIFESTO.ORG/
Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan
That is, while there is value in the items on the right, we valuethe items on the left more.
5 . 17
AGILE MICROSERVICES
DEVOPS
6 . 1
AGILE AND DEVOPS
6 . 2
WHAT IS DEVOPS?Agile relationship between Development
and IT Operations
6 . 3
Devops toolsCI Server (JenkinsCI - recommended, CodeShip, CircleCI etc.)
Git SCM
Ansible
Red Hat Mobile Application Platform
CI Server plugins (JenkinsCI pipeline, GitHub, Bitbucket plugins etc.)
Build tools (Gulp, Grunt, Maven, Gradle etc)
Testing frameworks (Mocha, Jasmin, Cucumber etc.)
Command line tools (fhc, oc, custom tools).
External services (GitHub, GitLab, BitBucket, Slack, IRC etc.)
Monitoring (Nagios)
6 . 4
INTEGRATION LIFECYCLE6 . 5
Text
TYPICAL PIPELINE6 . 6
Unit and Acceptance test best practices
Flexible deployment options
Lifecycle management
Health endpoints
Controlled UAT and Production deployment(cloud and MBaaS services)
App builds (build farm)
App deployment (MDM integration)
RED HAT MOBILE & DEVOPS6 . 7
AGILE
MICROSERVICES
DEVOPS
7 . 1
1
TRADITIONAL APPROACH
System of Record
Monolithic
Multi Featured
Long Development Cycle
Costly
Infrequent, Large Updates
THE MOBILE WAY
System of Engagement Simple, Nimble Apps Highly targeted to need Fast Development Cycle Affordable CD & CI
WHY MOBILEMICROSERVICES?
7 . 2
MICROSERVICESI T ' S J U S T S OA R I G H T ? !WHAT ARE THEY?
Small, composable servicesResponsible for small pieces of workTalk over "dumb" pipes, with "smart" endpoints
WHAT ARE THEY NOT?
MonolithsA "Silver Bullet"Just SOA Again
7 . 3
1
FAST TO DEPLOY
•Quick release cycle
•Loosely coupled API Integrations
PERFORMANT NETWORKCONNECTION
•Can make any request
•Payload size not a big concern
SLOW TO DEPLOY
•Release cycle up to 1-weekwith public app store reviews
•Tightly coupled API Integrations
LOSSY EDGE NETWORKS,3G BEST CASE
•HTTP overhead slow –need to make fewer requests
•Payload must be small- trimmed for mobile
MOBILE ISDIFFERENT
7 . 4
U P DAT I N G I S
DIFFERENT
7 . 5
P E R F O R M A N C E I S
DIFFERENT
7 . 6
MICROSERVICESA R E
Suited to mCOE Development Practices Suited to mobile Different from developing a monolith
7 . 7
AGILE DEVOPS MICROSERVICES
MOBILE COEBrings new release cycles
Brings a new pace of business
Delivers software differently
Gives greater ROI on $ IT spend
8
youtube.com/Red Hat
facebook.com/redhatinc
THANK YOU!
linkedin.com/company/red-hat @johnfriz
@deewhyweb
@cianclarke
9
SECTION HEADLINE
#redhat #rhsummit
10
SECTION HEADLINE
#redhat #rhsummit
11
SECTION HEADLINE
#redhat #rhsummit
12
MAJOR HEADLINES U BT I T L ESMALLER TITLE
normal text
#redhat #rhsummit
13
LEARN. NETWORK.EXPERIENCE OPEN SOURCE.
#redhat #rhsummit
14