An Infrastructure for Team Development - Gaylord Aulke


Published on

Published in: Business, Technology
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

An Infrastructure for Team Development - Gaylord Aulke

  1. 1. An Infrastructure for Team Based PHP Development Gaylord Aulke Director Professional Services DACH Zend Technologies
  2. 2. Agenda • Why am i talking here? (About the Speaker) • Motivation / The early days • About Processes • About Infrastructure • About Tools |
  3. 3. About me • Gaylord Aulke, 38, geek and sometimes businessman • Did some (serious) Assembler Coding in the past (40kb Machinecode) • Commercial Projects in Pascal (yes i am THAT old) • 4GL Business Application Coding (i was young and needed the money) • Started my Web-Life with Perl / CGI • Early Adoption of Java and J2EE (i love it) • Started using PHP in 1997 for very small projects only |
  4. 4. Motivation: The good old days Control/Start PM Deploy Change Server Test SAMBA Share Developer Test Apache QM |
  5. 5. Handcrafted approach • Everyone developed on a common Network share • Apache had its Docroot there • PROs:  Very simple to set up  FREQUENT integration of all changes  Easy to learn, no errors to make • CONs:  Editing a central file may render the application untestable for everyone  Conflict resolution must be done manually  Version Mgmt the hard way (.old, .old2, .veryold, .ancient)  Copying code base for concurrent codelines |
  6. 6. Motivation • We have serveral software projects • Some are under active development • Some in production and need occasional fixes • We have a limited number of Developers • Everybody needs to work on different projects • Context switches are normal and need to be efficient • We need to keep a high quality level • We want to scale the team and the customer base |
  7. 7. About Processes • Development • Integration • QS • Deployment • Maintenance |
  8. 8. Processes: Development • Every developer should be able to change and extend whatever he wants without restrictions • She should be able to test her changes very frequently in a realistic context • Changes of others must not influence the tests of her new code • After successfully testing the changes for themselves they need to be integrated with the changes of everybody else |
  9. 9. Processes: Integration • Usually, code runs in a certain environment in production • Developer needs a development Environment that is as close as possible to the production environment • Integration needs to be done as early as possible in the process • The „real“ integration is often only possible at the customer‘s site. A simple way to do this without risk is needed |
  10. 10. Processes: QS • „Quality“ is a process issue • Do reasonable tests already at development time  (test data, environment) • Integrate all code on a continuous integration Server • Test ALL functionality of the application frequently • Before a release do another test / approval process • Define measures and threshold for acceptable quality in all process steps |
  11. 11. Processes: Deployment • Automate deployment • Record all deployments made • If you have serveral customers: Manage the Deployment information centrally |
  12. 12. Processes: Maintenance • Manage Defects, Feature Requests, open issues and Requirements • Define a process for quick fixes/changes • Define a Release Process that coordinates Fixes and new Releases |
  13. 13. Local Development Scp/zip/rsync/ftp ProjectConfig DB Customer Servers Packager Deploy ! change Dev. DB. test Dev.Machine QS Machine test (all projects) Developers Checkoutdelete / Update /commitrevert / Checkoutdelete / SVN Repository QM Team |
  14. 14. Local development • Every developer runs his own copy of the application • A SCM (Source Code Mgmt) manages all the differerent changes and revisions of the Software  Lorna will talk about SVN in a few minutes • Changes are made to the local copy, local Apache has its docroot there • Developer tests locally until his component works • Then „check in“ to the repository is done |
  15. 15. About Databases • A common database for all developers usually does the job well because:  Changes are often backwards compatible (new fields, new tables)  Everybody can use shared test data  If the DB is corrupted, it can be re-built from scripts • Have a separate DB with „authentic“ test data for QS • Generate temporary DBs during runtime of automated tests (we create and drop these for every single test) • If a separate DB is needed, you can always copy… |
  16. 16. Issues with local Development • Everyone needs to build a local environment with all Extensions / PHP Versions etc. • Some environment details might only be available at a central location in one instance (an SAP system for example) • No Control about „the right environment“ |
  17. 17. How we cope with it • Define a common environment for all applications  Framework  Set of extensions to use • Define a common local apache and path setup • Put all environment information in config files • Manage local config files and Vhosts for this setup in the SCM • Build the application for portability (Windows Development Systems, Linux Servers) |
  18. 18. More Sophisticated: Development Sandboxes Scp/zip/rsync/ftp ProjectConfig DB Customer Servers Deploy ! Packager Deploy ! Priv. Workspace change Priv. Workspace Priv. Workspace Shared Workspace test Priv. VHost Priv. VHost Checkoutdelete / Priv. VHost QS VHost test Developers Checkoutdelete / Management Select project Application Select project checkout QM Team Update/commitrevert / SVN Repository |
  19. 19. Development Sandboxes: File Structure Dyn . Data Project#1 Core Custom Testserver Project#2 SymLink Docroot Project#3 BaseDir Slot#1 Dyn. Data Sandboxe Björn s Slot#2 Core Eric Custom Slot#3 Thomas Docroot |
  20. 20. Development Sandboxes • One Development Server • All Environment set up there • Everyone has his own area there where he can Checkout/Test • Every Developer has a number of „Project Slots“ that he can fill with any project (- revision) • Slots are re-used, can be freed after checkin |
  21. 21. Development Sandboxes • PROs:  Single Point of administration  Complete environment can be set up  A common set of tools can be used • CONs:  Quite complex in multi-project environments  Development / SCM checkout on network share  Single Point of Failure |
  22. 22. Middelway: VMWare • Build VMWare Image for each project with all dependencies • Use hgfs (host file system access) to access local code base (outside VM) • Host OS can mount shares in the network for shared files and test data • VM can use external or internal DB • Running a project is as easy as copy a VM, start it |
  23. 23. Packaging and Branching Live Branch Change #2 Change #4 Change #6 Merge Merge Development Change #1 Change #3 Change #5 Create live branch when development Each change in the live Deploy new development Version Version has been installed onthe live Branch is immediately to Customer Server Old Live Branch . Server. Merged to the dev branch . is deleted and then Created new from development branch . |
  24. 24. Packaging • Always have the current version that is installed on the customer‘s site in your SCM • Always follow the same process steps:  Change locally on your system  Test changes  Run automatic Deploy • To do so,  Manage configuration on customer‘s site in some tool  Build an infrastructure for deployment to different sites with different transport mechanisms |
  25. 25. Tools • IDE • SCM • Automated Testing / Metrics / Code Coverage • Code-Analyzing • Continuous Integration • Packaging / Deployment • Bug Tracking / Project management |
  26. 26. IDE: Zend Studio |
  27. 27. Zend Platform |
  28. 28. SCM • RCS works cool for config files • CVS can already manage development projects with many users • SVN is „the better CVS“ (which is already a question of believe for some) • GIT is extremely cool • Commercial tools are very different in focus and functionality/quality • We bought 80 Perforce licenses during New Economy times (600 $ per seat) and didn‘t regret it. |
  29. 29. Tesing: PHPUnit |
  30. 30. Selenium IDE |
  31. 31. PHP Code Sniffer |
  32. 32. Static Code Analyzer / Metrics • „Project Mess Detection“  PMD scans source code and looks for potential problems like:  Possible bugs  Dead code - unused local variables, parameters and private methods  Suboptimal code  Overcomplicated expressions - unnecessary if statements, for loops etc.  Duplicate code - copied/pasted code means copied/pasted bugs • Coding Style Check • Static Security analysis ( • Static Code Quality analysis (Zend Code Analyzer) • … |
  33. 33. Continuous Integration: Cruise Control |
  34. 34. Packaging/Deployment • Build-Tools:  ANT, PHING, RAKE, Shell Scripts • They can generate Packages (ZIP or RPM) • Deployment to Staging Server • Then local deployment to Cluster • Integrated Solution (Ruby): Capistrano (  Deploy, Rollback  Remote Execution via SSH • Puppet ( |
  35. 35. Packaging: What we do • Intranet-App that has a „deploy“ button for each Project • SCM Sync to Test-Server first (test-deploy-Button) • Run tests there • Then deploy to customer‘s site (deploy-life Button) • Sync to test server is done via SCM checkout • Sync to customer server is done with arbitrary shell script  ANT, PHING or RAKE for building packets  FTP, SCP, RSYNC or HTTP Upload to tansfer  Postsync Script on Target Machines to unpack, install |
  36. 36. Bug Tracking, Project Mgmt • Trac  Integrates with SCM,  many plugins  (example:  Manages Changes, Tickets, Wiki • ActiveCollab  More PM/Collaboration features, no SCM integration  • Phprojekt  More Groupware oriented  |
  37. 37. phpUnderControl • Cruise Control • PHPUnit • PHPCodeSniffer • PHPDocumentor • |
  38. 38. phpUnderControl |
  39. 39. Buildix Buildix includes: • Subversion for Source Control • Mingle for Agile Project Management • Cruise Control for Continuous Integration • Trac as a wiki and bug-tracker • …plus a little bit of our own ThoughtWorks magic, to glue it all together |
  40. 40. Learnings / Ideas • For Local development: Set up a local DNS server that resolves all project names to • Example: <projectname>.<customername>.local • For SCM servers, File System can make a big difference. Choose the right one! |
  41. 41. Reference to tools • Zend Studio: • Cruise Control: • Xinc: • Apache ANT: • PHP Alternative to ANT: • Subversion: • Tortoise SVN Explorer Extension: • Trac SVN+ Technical Project Management: • Nagios: • Zend Platform: • PHPUnit: • Selenium: |
  42. 42. Books I found useful • „Projekt-Automatisierung“, Mike Clark, Carl Hanser Verlag, München, 2006 • (english: „Pragmatic Project Automation – How to build …“, The Pragmatic Programmers, LLC. 2004 • Subversion Book: • “Effektive Softwarearchitekturen”, Gernot Starke, Hanser, 2005 • “Organisational Patterns for Agile Software Development”, Coplien, Harrison, Lucent Technologies, Prentice Hall, 2005 • “Test Driven Development. By Example”, Addison-Wesley, Kent Beck, 2002 |
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.