An Infrastructure for Team Development - Gaylord Aulke

  • 3,343 views
Uploaded on

 

More in: Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,343
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
122
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. An Infrastructure for Team Based PHP Development Gaylord Aulke Director Professional Services DACH Zend Technologies
  • 2. Agenda • Why am i talking here? (About the Speaker) • Motivation / The early days • About Processes • About Infrastructure • About Tools |
  • 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. Motivation: The good old days Control/Start PM Deploy Change Server Test SAMBA Share Developer Test Apache QM |
  • 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. 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. About Processes • Development • Integration • QS • Deployment • Maintenance |
  • 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. 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. 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. Processes: Deployment • Automate deployment • Record all deployments made • If you have serveral customers: Manage the Deployment information centrally |
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Tools • IDE • SCM • Automated Testing / Metrics / Code Coverage • Code-Analyzing • Continuous Integration • Packaging / Deployment • Bug Tracking / Project management |
  • 26. IDE: Zend Studio |
  • 27. Zend Platform |
  • 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. Tesing: PHPUnit |
  • 30. Selenium IDE |
  • 31. PHP Code Sniffer |
  • 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. Continuous Integration: Cruise Control |
  • 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. 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. 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. phpUnderControl • Cruise Control • PHPUnit • PHPCodeSniffer • PHPDocumentor • http://www.phpundercontrol.org |
  • 38. phpUnderControl |
  • 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. 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. 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. 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 |