An Infrastructure for Team Based PHP
Development
Gaylord Aulke
Director Professional Services DACH
Zend Technologies
Agenda

 •   Why am i talking here? (About the Speaker)
 •   Motivation / The early days
 •   About Processes
 •   About I...
About me

 • Gaylord Aulke, 38, geek and sometimes
     businessman
 •   Did some (serious) Assembler Coding in the past
 ...
Motivation: The good old days


                                             Control/Start




                           ...
Handcrafted approach
  • Everyone developed on a common Network share
  • Apache had its Docroot there
  • PROs:
     Ver...
Motivation
  •   We have serveral software projects
  •   Some are under active development
  •   Some in production and n...
About Processes

  •   Development
  •   Integration
  •   QS
  •   Deployment
  •   Maintenance




                    |
Processes: Development

  • Every developer should be able to change and
      extend whatever he wants without restrictio...
Processes: Integration

  • Usually, code runs in a certain environment in
      production
  •   Developer needs a develo...
Processes: QS

 • „Quality“ is a process issue
 • Do reasonable tests already at development time
      (test data, envir...
Processes: Deployment

  • Automate deployment
  • Record all deployments made
  • If you have serveral customers: Manage ...
Processes: Maintenance

  • Manage Defects, Feature Requests, open issues
      and Requirements
  •   Define a process fo...
Local Development

                                                            Scp/zip/rsync/ftp


                       ...
Local development

  • Every developer runs his own copy of the
      application
  •   A SCM (Source Code Mgmt) manages a...
About Databases
 • A common database for all developers usually
     does the job well because:
      Changes are often b...
Issues with local Development

  • Everyone needs to build a local environment with
      all Extensions / PHP Versions et...
How we cope with it

  • Define a common environment for all applications
       Framework
       Set of extensions to u...
More Sophisticated: Development Sandboxes
                                                                        Scp/zip/...
Development Sandboxes: File Structure
                                             Dyn . Data




                        ...
Development Sandboxes

 • One Development Server
 • All Environment set up there
 • Everyone has his own area there where ...
Development Sandboxes

 • PROs:
    Single Point of administration
    Complete environment can be set up
    A common ...
Middelway: VMWare

 • Build VMWare Image for each project with all
     dependencies
 •   Use hgfs (host file system acces...
Packaging and Branching



 Live Branch                          Change #2                       Change #4                ...
Packaging

 • Always have the current version that is installed
     on the customer‘s site in your SCM
 •   Always follow...
Tools

  •   IDE
  •   SCM
  •   Automated Testing / Metrics / Code Coverage
  •   Code-Analyzing
  •   Continuous Integra...
IDE: Zend Studio




                   |
Zend Platform




                |
SCM

 • RCS works cool for config files
 • CVS can already manage development projects
     with many users
 •   SVN is „t...
Tesing: PHPUnit




                  |
Selenium IDE




               |
PHP Code Sniffer




                   |
Static Code Analyzer / Metrics

  • „Project Mess Detection“
         PMD scans source code and looks for potential probl...
Continuous Integration: Cruise Control




                                         |
Packaging/Deployment
 • Build-Tools:
     ANT, PHING, RAKE, Shell Scripts
 • They can generate Packages (ZIP or RPM)
 • D...
Packaging: What we do

  • Intranet-App that has a „deploy“ button for each
      Project
  •   SCM Sync to Test-Server fi...
Bug Tracking, Project Mgmt

  • Trac
       Integrates with SCM,
       many plugins
       (example: http://www.agile4...
phpUnderControl

 •   Cruise Control
 •   PHPUnit
 •   PHPCodeSniffer
 •   PHPDocumentor
 •   http://www.phpundercontrol.o...
phpUnderControl




                  |
Buildix

  http://buildix.thoughtworks.com/

  Buildix includes:
  • Subversion for Source Control
  • Mingle for Agile Pr...
Learnings / Ideas

  • For Local development: Set up a local DNS server
      that resolves all project names to 127.0.0.1...
Reference to tools

  •   Zend Studio: http://www.zend.com/products/zend_studio
  •   Cruise Control: http://cruisecontrol...
Books I found useful
  • „Projekt-Automatisierung“, Mike Clark, Carl Hanser Verlag,
      München, 2006
  •   (english: „P...
Upcoming SlideShare
Loading in...5
×

An Infrastructure for Team Development - Gaylord Aulke

3,665

Published on

Published in: Business, Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,665
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
123
Comments
0
Likes
3
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 (www.armorize.com) • 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 ( http://capify.org/)  Deploy, Rollback  Remote Execution via SSH • Puppet (http://reductivelabs.com/trac/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: http://www.agile42.com/cms/pages/download/)  Manages Changes, Tickets, Wiki • ActiveCollab  More PM/Collaboration features, no SCM integration  http://www.activecollab.com/ • Phprojekt  More Groupware oriented  http://www.phprojekt.com/ |
  37. 37. phpUnderControl • Cruise Control • PHPUnit • PHPCodeSniffer • PHPDocumentor • http://www.phpundercontrol.org |
  38. 38. phpUnderControl |
  39. 39. Buildix http://buildix.thoughtworks.com/ 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 127.0.0.1 • 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: http://www.zend.com/products/zend_studio • Cruise Control: http://cruisecontrol.sourceforge.net/ • Xinc: http://code.google.com/p/xinc/ • Apache ANT: http://ant.apache.org/ • PHP Alternative to ANT: http://phing.info/ • Subversion: http://subversion.tigris.org/ • Tortoise SVN Explorer Extension: http://tortoisesvn.tigris.org/ • Trac SVN+ Technical Project Management: http://trac.edgewall.org/ • Nagios: http://www.nagios.org/ • Zend Platform: http://www.zend.com/de/products/zend_platform • PHPUnit: http://www.phpunit.de/ • Selenium: http://www.openqa.org/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: http://svnbook.red-bean.com/ • “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.

×