31
A Tale of Two Apps WHY DEVELOPMENT PRACTICES MATTER Z e n d c o n 2 0 1 3 1 O c t 8 2 0 1 3

A Tale of Two Apps

Embed Size (px)

DESCRIPTION

A Tale of Two Apps. Why Development practices matter. Who Am I?. Chris Tankersley Been Doing PHP for 9+ Years Lots of projects no one uses, and a few that some do: https://github.com/dragonmantank Worked in insurance for 4.5 years I know RPG!. What did we need to do?. - PowerPoint PPT Presentation

Citation preview

Page 1: A Tale of Two Apps

Zen

dco

n 2

01

31

A Tale of Two AppsWHY DEVELOPMENT PRACTICES MATTER

Oct 8

20

13

Page 2: A Tale of Two Apps

Zen

dco

n 2

01

32Who Am I?

Chris Tankersley

Been Doing PHP for 9+ Years

Lots of projects no one uses, and a few that some do: https://github.com/dragonmant

ank

Worked in insurance for 4.5 years

I know RPG!

Oct 8

20

13

Page 3: A Tale of Two Apps

Zen

dco

n 2

01

33What did we need to do?

“Build an app for agents to quote and issues new policies online, print ID

cards, and policy documents, and all the fun stuff associated with that.”

* ‘Fun Stuff’ was subjective

Oct 8

20

13

Page 4: A Tale of Two Apps

Zen

dco

n 2

01

34We had this… kinda

Backend iSeries vendor supplied a ‘solution’ for our Personal Auto policies

Only worked with Personal Auto

After many years, support was dropped

Oct 8

20

13

Page 5: A Tale of Two Apps

Zen

dco

n 2

01

35What did we have?

Oct 8

20

13

Page 6: A Tale of Two Apps

Zen

dco

n 2

01

36We needed a solution

We needed something that worked with our existing backend, which had all of our raters and business logic. We didn’t want to switch processing systems.

Turns out we had two things – a web app and a “RESTful” interface to the iSeries. The interface used ACORD XML, which is a standard XML schema. We could replace the web app with a new one that understood ACORD!

Oct 8

20

13

Page 7: A Tale of Two Apps

Zen

dco

n 2

01

37What we decided to do

Build one!

Purchase one!

We went with a vendor with a pedigree in insurance. They had a Tomcat+Postgres solution, and since the magical black box talked XML, they were confident they could swap out their rating system

with theirs. We’d be done in 6 months.

Oct 8

20

13

Page 8: A Tale of Two Apps

Zen

dco

n 2

01

38Their Solution

More on them later though

Oct 8

20

13

Page 9: A Tale of Two Apps

Zen

dco

n 2

01

39We finally build our own!

We needed to bring our commercial business online to help sell it. We had the technology (but not $6 million)

Oct 8

20

13

Page 10: A Tale of Two Apps

Zen

dco

n 2

01

310

Our SolutionO

ct 8 2

01

3

Page 11: A Tale of Two Apps

Zen

dco

n 2

01

311

Why Two Solutions?

Notice how I said that the Tomcat/Postgres app would be done in 6 months?

Yeah…

The app took much more time and budget than originally thought. How did we do a PHP app in 7 months and much less money?

Oct 8

20

13

Page 12: A Tale of Two Apps

Zen

dco

n 2

01

312

What was different?

Proper specifications

Development Lifecycle

Understanding your stack

Testing and QA

Deployment Practices

Oct 8

20

13

Page 13: A Tale of Two Apps

Zen

dco

n 2

01

313

Proper Specifications

Functional and technical specifications are a must. If you don’t know what you are building, how will you know how to build it? Or when it’s finished?

Oct 8

20

13

Page 14: A Tale of Two Apps

Zen

dco

n 2

01

314

There is a difference between this O

ct 8 2

01

3

Page 15: A Tale of Two Apps

Zen

dco

n 2

01

315

And ThisO

ct 8 2

01

3

Page 16: A Tale of Two Apps

Zen

dco

n 2

01

316

Development Lifecycle

Waterfall

Spiral/Prototype

Agile (SCRUM, Kanban, etc)

Oct 8

20

13

Page 17: A Tale of Two Apps

Zen

dco

n 2

01

317

They used WaterfallO

ct 8 2

01

3

Page 18: A Tale of Two Apps

Zen

dco

n 2

01

318

We used Agile-ish-stuffO

ct 8 2

01

3

Page 19: A Tale of Two Apps

Zen

dco

n 2

01

319

Understanding Your Stack

If you don’t know how your stack works, it makes it really hard to figure out problems with things go belly up.

Oct 8

20

13

Page 20: A Tale of Two Apps

Zen

dco

n 2

01

320

Their StackO

ct 8 2

01

3

Page 21: A Tale of Two Apps

Zen

dco

n 2

01

321

Our StackO

ct 8 2

01

3

Page 22: A Tale of Two Apps

Zen

dco

n 2

01

322

Testing and QA

You do test your code, right?

How do you prove your code works?

Can anyone run your tests or are they only accessible to certain people?

Oct 8

20

13

Page 23: A Tale of Two Apps

Zen

dco

n 2

01

323

They used only “HP Functional Testing”

As the name implies, it just did functional testing. In the end, it was a very expensive Selenium.

While they wrote in Java, they did not use (nor understand why anyone would use) JUnit or other unit testing frameworks.

Because it was cost prohibitive, we could not run tests.

Oct 8

20

13

Page 24: A Tale of Two Apps

Zen

dco

n 2

01

324

We used standard PHP tools

PHPUnit We settled on PHPUnit for unit testing. It was/is

widely documented and we even managed to get it to run on the iSeries.

Selenium We manually ran these tests as we hadn’t worked

out how to get it to run headless. Not a big deal because we had to support IE, which only supported manually running it anyway.

phpUnderControl This ran PHPUnit automatically for us and built

our documentation

Oct 8

20

13

Page 25: A Tale of Two Apps

Zen

dco

n 2

01

325

Unit Testing Works!

Using unit testing and continuous integration, we were able to detect test failures right away. Being able to run PHPUnit on the iSeries helped us identify and fix platform-specific bugs. Since developers could run PHPUnit and Selenium locally, we had less regressions.

Since HP Functional Testing was expensive, only the vendor could run the functional tests so developers (even at the vendor) never knew when the tests broke. Since it was only functional, it didn’t find subtle bugs in the code.

Oct 8

20

13

Page 26: A Tale of Two Apps

Zen

dco

n 2

01

326

Deployment Practices

Continuous Integration Tools (Jenkins, xinc/phing)

Build file with manual deployment

Custom deployment script

Hope and a Prayer

Oct 8

20

13

Page 27: A Tale of Two Apps

Zen

dco

n 2

01

327

We went the custom route

1. Tagged trunk in SVN

2. Script checked out the build, SCP’d it to the iSeries

3. MySQL Updates were applied by the script

This worked pretty well considering we could tag a revision in SVN that passed tests, which we could

check via phpUnderControl.

Oct 8

20

13

Page 28: A Tale of Two Apps

Zen

dco

n 2

01

328

They went with the last option

1. The code on the dev server was packaged as a WAR file

2. The SQL needed for the upgrade was put into a file

1. Sometimes multiple SQL files that would need to be run in order

3. A zip file was created from this

4. It was e-mailed to us

5. We put the WAR file into place and ran the SQL files manually against Postgres

6. Tomcat was restarted

tl;dr: Stuff blew up regularly

Oct 8

20

13

Page 29: A Tale of Two Apps

Zen

dco

n 2

01

329

Putting it all together

Auto Quoter Originally 6 months to production and small price

tag. Ended up being way over budget and way over time. When I left, it had just barely gotten to where v1 had originally been. This was due to poor specs, poor QA, and poor development practices.

Artisan Quoter We ended up 1 month over time, but much

cheaper (even when payroll was considered). It ran on existing hardware, so the software cost only ended up being Zend Server.

Oct 8

20

13

Page 30: A Tale of Two Apps

Zen

dco

n 2

01

330

Questions?O

ct 8 2

01

3

Page 31: A Tale of Two Apps

Zen

dco

n 2

01

331

Thank You!

[email protected]

@dragonmantank

https://joind.in/9070

Oct 8

20

13