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
Dec 27, 2015
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
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
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
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
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
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
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
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
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
Zen
dco
n 2
01
316
Development Lifecycle
Waterfall
Spiral/Prototype
Agile (SCRUM, Kanban, etc)
Oct 8
20
13
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
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
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
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
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
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
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
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
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
Zen
dco
n 2
01
331
Thank You!
@dragonmantank
https://joind.in/9070
Oct 8
20
13