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