A TALE OF TWO APPS WHY DEVELOPMENT PRACTICES MATTER

Size: px

Start display at page:

Download "A TALE OF TWO APPS WHY DEVELOPMENT PRACTICES MATTER"

Alban Sherman
5 years ago
Views:

1 A TALE OF TWO APPS WHY DEVELOPMENT PRACTICES MATTER

2 WHO AM I? PHP Developer for about 9 years Worked in insurance for 4.5 years I know RPG! (Not that good at it though)

3 WHAT DID WE NEED TO DO? Build an app for agents to quote and issue new policies online, print ID cards and policy documents, and all the fun stuff associated with that. * 'Fun Stuff' was subjective

4 WE HAD THIS... KINDA Backend iseries vendor supplied a 'solution' for our Personal Auto policies Only worked for Personal Auto After many years, support was dropped

5 WHAT DID WE HAVE

6 WE NEEDED A SOLUTION We needed something that worked with our existing backend which had our raters and business logic. We didn't want to switch policy processing systems. Turns out we had two things - a web app and an 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!

7 WHAT WE DECIDED TO DO BUILD OUR OWN! 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 ours. We'd be done in 6 months. This was good - time to market was extremely important.

8 THEIR SOLUTION

9 MORE ON THEM LATER

10 WE FINALLY BUILD OUR OWN! We needed to bring our commercial business line online to help sell it. We had the technology (but not $6 million).

11 OUR SOLUTION

12 WHY TWO SYSTEMS? Notice how I said 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?

13 WHAT WAS DIFFERENT? Proper Specifications Development Lifecycle Understanding Your Stack Testing and QA Deployment Practices

14 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 is finished? THERE IS A DIFFERENCE

15 BETWEEN THIS

17 AND THIS

19 DEVELOPMENT LIFECYCLE The structured plan in which you build your software. Waterfall Spiral/Prototype Agile (Scrum, Kanban, etc)

20 THEM - WATERFALL

21 US - SCRUM+KANBAN+AGILE = SOMETHING

22 UNDERSTANDING YOUR STACK If you don't know how your stack works, it makes it really hard to figure out problems when things go belly up.

23 THEIR STACK

24 OUR STACK

25 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?

26 PHPUNIT We settled on PHPUnit for unit testing. It 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 manually run it in IE anyway. PHPUNDERCONTROL This ran PHPUnit automatically and built our documentation.

27 HP FUNCTIONAL TESTING As the name implies, it just did functional testing. In the end it was a very expensive Selenium. * They tried to get us to buy it, touting it as a better replacement for unit testing and Open Source toolkits. It would also allow us to run the tests instead of them.

28 UNIT TESTING WORKS! Using unit testing and continous integration, we were able to detect test failures right away. Being able to run PHPUnit on the iseries helped us identify and fix platformspecific bugs. Since developers could run PHPUnit and Selenium locally, we had less regressions. Since HP Functional Testing was expensive, only certain people could run the functional tests so developers never knew when they introduced regressions or broke the build. Since it was only functional tests, it didn't find all of the bugs in the code.

29 DEPLOYMENT PRACTICES How do you get code from development, to QA, to production? Continuous Integration Tool (Jenkins, xinc/phing) Build file with manual deployment Custom deployment script Hope and a Prayer (Manually moving stuff)

30 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.

31 THEY DIDN'T The code on the dev server was packaged as a WAR file 2. The SQL needed for the upgrade were put in a file 3. A ZIP file was created from this 4. It was sent via to us 5. We put the WAR file in place and ran the SQL script 6. Tomcat was restarted tl;dr - Stuff Blew Up Regularly

32 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.

33 THE END ANY QUESTIONS? Chris (Twitter, app.net)

Shift Left and Friends And What They Mean for Testers

Shift Left and Friends And What They Mean for Testers And What They Mean for Testers Replica of the shift left persuasion device (i.e., 2x4) used by a test manager colleague in 1990s Introduction All the IT world is abuzz with the latest buzz words Shift