Your SlideShare is downloading. ×
How to run an Enterprise PHP Shop
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

How to run an Enterprise PHP Shop


Published on

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 …

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.

Published in: Technology

1 Comment
  • cool dude...
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 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.
  • 8. The Building Blocks For Your Team
      • Team Management
      • Development
      • Testing
      • Maintenance
      • Security
  • 9. Team Management: Building your team
      • Where to find developers
      • How to interview them
  • 10. Where to find developers
    • Don't always rely on HR, Monster and Dice
      • IRC PHP Channels
      • Craigslist jobs/gigs section
      • Blogs of active developers
      • Previous jobs
    • These are all places I've found developers on our team.  People also tend to feel more confortable knowing a developer is contacting them vs a recruiter.
  • 11. How to interview developers
      • Determine fluff vs fact on a resume
      • Set up phone interviews
      • Determine when it's worth bringing someone in
      • Set up in person interviews with team
      • ZCE's
  • 12. In Person Interview
      • Determine the order of the team members ahead of time. 
      • Have a brief technical test ready that covers a wide area of what you need.
      • Have the candidate take the test first with HR, then start the interview process.
      • Ask the right questions.
      • The test should not be the determining factor but merely part of the process.
  • 13. Wrong Questions
    • Why I don't favor these types of "thinking" questions:
      • Most people who ask this aren't qualified to determine the thought process for the answer given.
      • It generally has no relevant bearing on the position
    How would you load an elephant on a 787?
  • 14. Better Question
    • Why I think this type of question is better:
      • There is no right answer but it becomes clear exactly how much experience someone has. Do they start at the network level, load balancers, clusters, caching, dbload, hardware failures, browser level, user error, profile the code, check the logs, run performance test suite, work with the user on reproducing the issue
      • You're qualified to understand their thought process
    A user reported the website is running slow. What steps do you take to address the issue?
  • 15. Other good phone questions I like
      • What features in PHP5 do you like the most that weren't available in PHP4?
      • When a user types in a web address in their browser and hits go, what happens behind the scenes?
      • Explain a design pattern you've used in the past that's helped your architecture
      • What's Unit testing? What's your approach to testing
      • Explain the differences between GET and POST, why would you choose one over the other in your application?
      • What is XSS (cross site scripting)?
      • What is SQL Injection?
      • What steps do you take in your coding to minimize vulnerabilities?
  • 16. Development
    • Several fundamental concepts required to create a maintainable development environment. 
      • Setting Developer Expectations
      • Documentation Standards
      • Source Control Management
      • Coding Standards
      • Unit Testing Standards
      • Release Process
      • Making developers more valuable
  • 17. Development: Setting Developer Expectations
    • When new developers come on board you need to define what you expect from them.
      • Follow the standards laid out by the team (source, docs, unit testing, etc...) 
      • Automate and have backup procedures
      • Be accountable for their work
      • Be able to create documentation / use the wiki
      • Communicate openly
      • Core hours
  • 18. Development: Documentation Standards
    • If you find yourself in charge of requirements or you need to work with your internal groups to define requirements you really only need three documents. 
      • Requirements Document
      • Design Document
      • Test Plan Document
  • 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.
  • 20. Requirements Document
    • Here are some examples of what would typically appear in a requirements document.  
      • REQ123 - A User shall be able to search for a  product
        • REQ123.1 A user can use a wildcard search such as "*" or define a particular field such as "year:2003"
    • What is not a requirement:
      • REQ124 - System shall be easy to use (not testable)
  • 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.
  • 22. Design Document Contents
      • REQ123 - A User shall be able to search for a  product
        • year, vintage, winery are valid search fields
        • The search is implemented using Zend Lucence, each field is created as a tokenized element. 
        • The search index is stored in the application's temp directory. 
        • The index is regenerated every 24 hours via a cron job that runs on the server.
  • 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.
  • 26. Source Control Management
      • There is no right tool, just make sure you have a tool
      • Make sure that everyone follows the best practices set by the team leads.
      • Pick the appropriate tool for your team and dev platforms.
        • Is your team distributed? Perhaps GIT
        • Windows Only? VSS
        • Mix of platforms? SVN. CVS
  • 27. SCM Rules
      •   Your source should be backed up both on and off site
      • At least 1 person should be in charge of the administration of monitoring that product. (At a previous job we found out the SCM admin hadn't backed up the source in weeks due to a failing backup script).
      • Branch a release, only release a branch
      • Incorporate continuous integration hooks
  • 28. Coding Standards
      • Pick a coding standard and stick with it (PEAR, Zend, etc)
      • Create an environment that promotes developer peer reviews
      • If it becomes a contention point for the team, use an automated plugin to inspect checked in code vs team standards (PHP CodeSniffer)
  • 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.
  • 30. Life Before A Framework
    • What was the problem?
      • Numerous tool sites all coded in different styles and languages. 
      • Operations team had different deployment strategies for each
      • No roll up reporting across content tools
      • Dozens of sites to maintain and secure
  • 31. Life Before A Framework No sharing of code bases, no common standards for security, access control, authorization, UI presentation, reporting .
  • 32. Why I chose Zend Framework for Enterprise
      • Large user base
      • Company behind the product
      • Training / Consulting available
      • Products built around the framework
      • Modular design
      • Can use components individually
      • Large feature set
      • Heavily unit tested
      • Can get new developers up to speed with minimal instruction
  • 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.
  • 34. The myth that Zend Framework is slow
      • Developers are expensive, hardware is cheap(usually)!
      • Opcode cache increases performance considerably
      • Memory caching (memcached)
      • Disk based caching
      • Database tuning(proper indexing, multi-tier)
      • Specialized AJAX bootstrap
    • Weigh the cost and time of all decisions.
  • 35. Unit Testing   Code does not exist until it's tested. The "Liger" Effect  
  • 36. Unit Testing: The Gift that Keeps On Giving
      • Unit tests should be a cornerstone of your development
      • They're no longer "optional"
      • What is Unit vs Integration?
      • Continuous Integration after every checkin
      • Include the time for unit tests in your estimates
  • 37. Unit Testing: The Cornerstone
      • Standards should be enforced teamwide as to what the testing expectations are. 
      • Code should not be checked in without tests behind it
      • At the bare minimum the business logic should have a high code coverage level. 
      • PHP Unit can be run with XDebug's code coverage to allow you to see exactly what code was run.
      • Aim for % of acceptable covereage
      • Tie in Unit Test Coverage to bonuses/reviews
      • Hold team meetings to help get new developers on board
  • 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 ('')                                       -> 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.
  • 50. Release Process: Dev Servers
      • Should allow developers full access to system
      • Should run on production type hardware with production OS and libraries
      • Should support multiple dev instances of a site
      • Should be able to be wiped out without ramifications
      • QA should use to develop test cases and automation
  • 51. Release Process: Test Servers
      • Should be a mirror of production environment
      • Should be controlled by operations team
      • Issue should be created with branch or package to push to test and assigned to ops team
      • QA runs automation and regression tests against
      • Code on test should be the same code targeted to a production release
      • Code pushed to test should be based on a branch of the code
  • 52. Release Process: The bug bash
      • The bug bash is a pre-release event before a major milestone release to flush out uncaught issues.
      • Generally held after hours with people from across the company
      • Prizes awarded
      • Food provided
      • Team atmostphere
  • 53. Release Process: The bug bash
      • Have one or more people from the bug scrub team monitoring and filtering the issues tracker live. 
      • Award cash prizes for most bugs found, most severe bug, most show stoppers, biggest security hole.
      • Budget this cost into your initial project estimates. 
      • It's better for people in the company find major bugs before customers.
      • Everyone meets in one or more conference rooms with laptops or desktops set up.
      • Developers do not test their own code
      • Don't assume you can release the day after a bug bash, estimate some time to address show stoppers.
  • 54. Maintenance
      • Issue Tracking
      • Working with Testers
      • Customer Support
      • Monitoring
  • 55. Issue Tracking
    • A common issue tracking system must be used across the teams. 
    • The issue tracking life cycle at a high level:
      • Issue reported
      • Issue verified/rejected
      • Issue assigned to a release and fixed
      • Reporting user notified of status
  • 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.
  • 57. Issue Tracking: Bug Scrubs
    • The bug scrub meetings should be as brief as possible, technical details should be handled offline with the appropriate parties. 
    • Bug Scrub Flow:
      • View open issues/feature requests
      • If already assigned and processed
        • follow up with owners as to why the item is still outstanding
      • If open
        • Reject or accept
        • Assign a release and owner to with information discussed
  • 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
  • 60. Monitoring: System and Business
      • The operations team should not only monitor the system processes but have the developers contribute plugins for business processes as well.
      • e.g., set a min threshold for how many users you expect to sign up in a given hour, if under that threshold notifications go out. This may indicate a problem with the sign up form.
      • ProActive business rule monitoring allow faster response times to application issues
  • 61. Monitoring: Disaster Recovery
      • A Disaster recovery plan should be created, implemented, tested and made available to all parties. 
      • Ideally your disaster recovery site should be located outside unstable areas.
        • if primary is in earthquake prone area, backup should be elsewhere
        • if primary is in an unstable country politically, backup should be elsewhere
      • Disaster recovery is just that... for Disaster, hardware failures should be handled by your primary site by taking the node offline. 
      • Proper monitoring should allow automatic fail over.
      • Data should be propagated over on a regular basis. (snapmirror)
  • 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.
  • 63. Security
    • Security is often a last thought on dev teams
      • Plan to be attacked
      • Code defensively
      • In-House Social Engineering
      • Security Audits
  • 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...
  • 65. Security: Code Defensively
      • Did a user's browser profile just change? Have them re-login (mitigate session hijacking)
      • Filter all input
      • Escape all output
      • Encrypt/hash(with salt) all passwords
      • If backend is networked across un-trusted network segments, encrypt transmission to avoid man in the middle attacks.
      • Don't offer clues to attackers on create/login pages(user account found but password is invalid)
  • 66. Security: Social Engineering
      • Plan random social engineering attempts against administrators/data holders.
      • How much information about your clients/sites is available on searches? 
      • How easily is it to use that information to make educated attacks? 
      • If new user accounts must be authorized first, is there a concrete plan in place to verify information.
      • Use email and phone to gather information and make requests.
  • 67. Security: Audits
      • If possible budget for quarterly/annual security audit
      • Set up a separate non-production instance
      • Pick a 3rd party who specializes in this field
      • Audit the application and the network independently. 
  • 68. The End contact: twitter: jiminoc