Falcon Invoice Discounting: Empowering Your Business Growth
An Infrastructure for Team Development - Gaylord Aulke
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
|
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.
|
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/
|
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!
|