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
|