This talk was geared around the concept of showing developers what goes into getting enterprise products out the door. Unit testing, release process, continuous integration, security, social engineering, bug bashes.

1. ZendCon09 How to run an enterprise PHP shop. By Jim Plush - Technical Lead, Panasonic

2. Writing Code is the Easy Part A closer look at some of the process that goes along with being a technical lead.

3. Balancing process and productivity

4. The balance between process and productivity The main objective is to find the least amount of process required to get clean, stable, well tested, well documented, maintainable code. If there is too much process, productivity and creativity are stifled. Too little process and you run the risk of delays, instability, maintability concerns and customer dissatisfaction. This balance is something that needs to be revisited often with feedback from the teams.

5. The importance of balance When process is so cumbersome that it hampers productivity, it will slow product delivery. Longer product delivery cycles create openings which startups and competitors will take advantage of. This is how companies not only lose market share but also high performing employees due to the barriers put in place that prevent them from doing their jobs efficiently.

6. Why Process? The larger your application grows, the more important foundation becomes.

7. When process fails The larger your application grows the more important foundation becomes.

19. Documentation: What's the difference? A Requirements Document is a contract between the client (even internal users) and the application. It should use terminology that is easily read by management and non-technical stakeholders. Even in an agile process a requirements document should be flushed out at a high level before starting development. The requirements document is how you know when something is done.

21. Design Document The design document is aimed at the technical and testing audience. It is used to define how to actually implement the system you're designing. UML, schema designs, API lists can all go into the design doc. The design document should outline how the system makes decisions and what constraints are placed on them. The Quality Assurance team should be able to create a test plan based on this document.

23. Test Plan Document The test plan document is used by the QA team to verify the requirements and design are met and can be tested against every release. The test plan is used to create automation against (Selenium, WinRunner, etc) Automation of the test plan ensures consistent user experience.

24. Test Plan Contents REQ123 - Search for product Test Cases ID: 1 Action: Create a new product then type in the product name in the search bar Expected: The product that was created appears in the search list Actual Result: Pass/Fail: Comment:

25. Documentation: But I just want to code This is where setting team expectations comes in. Documentation is part of the job of any engineer, including software engineers. It helps new product managers, stakeholders, developers get an understanding of what a product is supposed to do and why it's doing it. The goal should not be to generate the most documentation but "enough" documentation to get the job done.

29. Frameworks In multi developer environments it makes sense to invest in frameworks. At a high level Zend Framework, Cake, Symphony all offer similar feature sets. To maximize code reuse standardize on a single one for the team. Frameworks cost upfront time but that is paid back many ways down the line.

31. Life Before A Framework No sharing of code bases, no common standards for security, access control, authorization, UI presentation, reporting .

33. After Zend Framework Sites are plugged in as modules. Allowing for complete sharing of all features, giving the user a consistent experience while also getting the benefits of easier deployments and maintenance for the operations team.

35. Unit Testing Code does not exist until it's tested. The "Liger" Effect

38. Unit Testing: Unit vs Itegration Generally a unit test is considered a unit test when you're testing one coheisive action. A unit test may span multiple classes if you control those classes. Once a test touches 3rd party libraries or external resources (databases, filesystem, web service) it's generally considered an integration test. If your test class needs a tear down method you most likely have an integration test.

39. Unit Testing: Unit vs Itegration So what's the rub against integration tests? Answer: NONE! Most web applications benefit more from integration tests. Both require a decent amount of setup (resource management vs mock management). Your suites should include both however for speed purposes you may want to separate the integration tests into a separate suite due to the slower run time.

40. Unit Testing: Itegration testing practices Use Builders to help with schema change If my test requires a new user to test against I could insert that into the db by hand which would lead to brittle tests if you have 3000 tests and all the sudden you change the user schema. Or I could use a UserBuilder to abstract that API to a central place.

41. Unit Testing: Builders public function testUserCanUpgradeStatus() { $userBuilder = new UserBuilder(); $user = $userBuilder -> withFirstName ('Jim') - > withEmail ('jim@test.com') -> build (); $user -> upgradeToStatus ('preferred'); $this -> assertTrue ($user-> canReserveSuite () === true, "User was not able to upgrade to preferred status"); }

42. Unit Testing: Builder Benefits Using Builders allows you to abstract the creation of test data into a series of fluent APIs. Tests are no longer as brittle with all tests now using Builders instead of direct SQL manipulation. You can have as many builders as you need! UserBuilder, CompanyBuilder, ProductBuilder, OrderBuilder, etc...

43. Unit Testing: Builder Performance Benefits Using Builders can also speed up your integration suite as the builder can be combined with object caching or data caching to reduce the duplicate data that exists across tests. If 1000 tests use the same User information to base tests against, return the instance of the 1st created one (if unchanged).

44. Unit Testing: Continuous Integration

45. Unit Testing: Continuous Itegration The goal of continuous integration is to spot issues early and reliably. You create a script that runs every x seconds or monitors your repository. When it detects a change it grabs that code, packages up your project, runts the unit test suites, and alerts developers of any immediate issues. Common CI Frameworks: PHPUnderControl, Xinc, CruiseControl, or write your own. The concepts are simple.

46. Unit Testing: Continuous Itegration Your script should be fully automated and reliable. If there is a failure it's the teams priority to address it. If the code passes all of the tests, package it up and make it available for non-developers or QA teams (if needed). Developers should checkin early and often as pieces are complete. Every checkin should be uniquely validated against to have fine grained reporting on which change "broke" the build.

47. Release Process: Getting Code to Customers The release process defines who, how, and when code is release to a production environment.

48. Release Process: Quality Expectations Local Dev Test Production

49. Release Process: Best Practices Minimizing release issues can save time and headaches. If there is one thing you should define first, it's your code release process. It should be controlled and precise. Developers generally should not be pushing to test or production.

56. Issue Tracking: Bug Scrubs A bug scrub is a daily or weekly meeting with technical leads, managers and product managers with the aim of addressing the open issue list for a give project or projects. The goal is to make sure bugs/feature requests are addressed in a timely manner with the appropriate release tags and supporting information. Issues can be rolled into iterations as they get processed.

58. Issue Tracking If the issues are tagged with the appropriate release information, QA is able to pull a report from the system to use for release testing without having to guess at what's in the release or rely on developer's memories. If issues are further labeled with modules or functional pieces of code, metrics reports can be run that can identify key pieces that made be candidates for re-factoring or redesign. e.g., if 60% of the issues are in user management, more testing efforts can be directed to it.

59. Customer Support After a major release you have to expect an increased flow of issues into the system. Daily bug scrubs may be required to properly filter out duplicates and "training" issues. Set up a front line person that can immediately filter and address issues as they come in. Rotate this position around the team weekly. This allows everyone to get a glimpse into how the customers interact with the system and where the areas of concern are so they can apply those to future development

62. Monitoring: Disaster Recovery Execute your disaster recovery at least once to ensure procedures work correctly for moving the pointers to the secondary data center but also for moving that data back to the primary when and if it's made available again. You don't want to guess that your D.R. site works.

64. Security: Plan to be attacked If your site offers any value, chances are it will be probed by malicious users. The value of your data directly correlates to the intensity of the attacks. You should proactively monitor security breaches both in the operations team and in code. Have a plan of action to take when an attack has been verified. What information to log, authorities to notify, upper management notices, etc...

68. The End contact: jiminoc@gmail.com litfuel.net/plush twitter: jiminoc http://joind.in/talk/view/931