2. About Me
• Lorna Mitchell
• PHP Developer/Consultant/Trainer with Ibuildings
• ZCE
• Member of http://www.phpwomen.org
• Personal blog at http://www.lornajane.net
2
3. SVN and Deployment
• Deployment process
• Deployment mechanism
• Subversion
• Other tools
3
4. In The Beginning
• One Developer
• Code on PC
• FTP / SCP / Upload to live server
• It works!
4
5. Early Development Team
• More developers
• Development server
• Ideally one copy per developer, a testing/staging
server and a live platform
Dev
LIVE area
Dev
Dev
area
area
Staging
Dev Dev
area area
5
6. Deployment Considerations
• Multiple platforms prompt context-aware
configuration
• File permissions may need checking, for example
on cache directories
• If the live site has uploaded files stored in the file
system, need to preserve this content
• Compile step for initialising compiled templates or
populating caches
6
7. Deployment Plan
• A deployment plan is a recipe for moving code
• Step-by-step instructions for setting up a new
version of code
• Must always be accompanied by a rollback plan
• This process should be as automated as possible
7
8. Example Deployment Plan
• Avoid missing steps when putting live
Export from repository
Tar
Upload
Untar
Set permissions
Switch symlinks
8
9. Symlinks
Live-site (symlink)
Existing live code New code version
existing ready
preparing
9
10. Code Transport
• Copy development code to live
• Rsync development code to live
• Check out to live and update
• Export to live
• Patch changes from last live version only – requires
version meta-data
10
11. Commit Hooks
• Subversion can run scripts on given events, called
“commit hooks”
Pre-commit
Post-commit
• Run test suite
• Coding standards conformance
• Syntax check
• No “forgetting” any steps
11
12. Notifications
• Can use the commit hooks to trigger information
• Email team
Diff
Changes
Test coverage/outcomes
• Ticker/big screen
• Nabaztag
12
14. Source Control Clients
• Command line tools
• TortoiseSVN: http://tortoise.tigris.org
• IDE Plugins: for Zend Studio, Komodo, etc
• WebSVN: http://websvn.tigris.org
SFM (Safe For Managers)
• Trac: http://trac.edgewall.org/
14
15. Source Control Concepts
• Individuals communicate with repository
• Keeping place
• Collaboration tool
• Historic versions
15
16. Collaboration
• Two people operate on different files
Changes are combined
• Two people change the same file
Changes are merged if changes don't overlap
• Allows teams to easily work on different parts of
the system
16
18. Conflicts
• Two people edit the same part of the same file
Includes both adding a new method to the end of a class
• Subversion will notify you of the conflict and
provide:
Your most recent version
The version from the repository
Its best guess at a merge with some notation for where
the overlaps are
18
22. Branching Example
trunk
version 1.1
Development done,
merge in changes
version 1.2
development branch
bug fix
Delete extra
branch
bug fix
backport
22
23. Tagging Versions
• Source control tools allow you to label releases,
called “tags”
• Subversion has one revision number for a whole
repository, incrementing on every commit
• CVS has one revision number per file
• In either case its nice to have “client preview” or
“release 4.11” as human readable markers
23
24. Repository Structure
• Repository layout choices
• Deployment point choices
• Affected by process
• Dependent on product type
24
25. Cyclic Releases
• Periodic release cycle
• Need to maintain existing version
• Start developing new version
• May need to fix bugs in both versions
• Use branching
25
26. Continuous Releases
• Changes to branch
• Branch merged to trunk
• Can patch changes from branch to trunk for bug
fixes
• Deployment from trunk
26
27. Branch Deployment
trunk
version 1.1
development branch
version 1.2
testing
deployment!
27
28. Live Branch
• Changes to branch
• Branch merged to trunk
• Testing performed on trunk
• Changes then patched to live branch
• Deployment from live branch
28
29. Live Branch Deployment
trunk live branch
development branch
testing
deployment!
approved
changes
29
30. Database Versioning
• Copying exported versions around
Risk losing live data
• Make structure changes to all platforms
Put objects in scripts
• Simple patching strategy
No direct database operations
Numbered patch files in subversion
Include patches in script
Give database awareness of current patch level
Keep an installation script updated with all changes
30
31. Database Rollback
• Write patch file
• Also write undo file
-- release.2.0.sql
create table friends(
user_id int not null
friend_user_id int not null
created_date timestamp default current_timestamp not null
);
-- release.2.0.undo.sql
drop table friends;
31
32. DbMorph
• Tool developed by Maggie Nelson
• DbMorph, very early version http://sourceforge.net/
projects/dbmorph
• Also see Maggie's homepage
http://objectivelyoriented.com
• Slides from her talk at php|tek “Keeping Your
Database and PHP in Sync”
32
33. Other Tools
• Phing http://phing.info
Project build system based on Apache Ant
XML configuration
Integration with SVN
Available through PEAR
• Phar http://pecl.php.net/package/phar
Package management for PHP
Like JAR for Java
Self-extracting option
PECL module
33
34. SVN and Deployment
• Deployment process
• Deployment mechanism
• Subversion
• Other tools
34