PHP Deployment With SVN
Upcoming SlideShare
Loading in...5
×
 

PHP Deployment With SVN

on

  • 48,559 views

Talk from the Dutch PHP Conference 2008 about deploying PHP with Subversion. Includes mention of a nabaztag

Talk from the Dutch PHP Conference 2008 about deploying PHP with Subversion. Includes mention of a nabaztag

Statistics

Views

Total Views
48,559
Views on SlideShare
47,042
Embed Views
1,517

Actions

Likes
36
Downloads
646
Comments
0

16 Embeds 1,517

http://www.lornajane.net 1101
http://www.slideshare.net 289
http://josedasilva.blogs.sapo.pt 52
http://web.lornajane.net 20
http://beta.lornajane.net 16
http://www.linkedin.com 8
http://localhost 8
http://www.thewebhatesme.com 8
http://developer.tradekey.pk 4
http://www.schoox.com 3
http://phpmysqlquestion.blogspot.com 2
http://www.techgig.com 2
http://webcache.googleusercontent.com 1
http://translate.googleusercontent.com 1
http://stream.alcidesfonseca.com 1
https://duckduckgo.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    PHP Deployment With SVN PHP Deployment With SVN Presentation Transcript

    • PHP Deployment with Subversion Lorna Mitchell Ibuildings The PHP Professionals Ibuildings
    • 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
    • SVN and Deployment • Deployment process • Deployment mechanism • Subversion • Other tools 3
    • In The Beginning • One Developer • Code on PC • FTP / SCP / Upload to live server • It works! 4
    • 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
    • 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
    • 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
    • Example Deployment Plan • Avoid missing steps when putting live Export from repository Tar Upload Untar Set permissions Switch symlinks 8
    • Symlinks Live-site (symlink) Existing live code New code version existing ready preparing 9
    • 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
    • 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
    • Notifications • Can use the commit hooks to trigger information • Email team  Diff  Changes  Test coverage/outcomes • Ticker/big screen • Nabaztag 12
    • Source Control Packages • Subversion http://subversion.tigris.org • CVS http://www.cvshome.org • GIT http://git.or.cz • Bazaar http://bazaar-vcs.org • Visual Source Safe 13
    • 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
    • Source Control Concepts • Individuals communicate with repository • Keeping place • Collaboration tool • Historic versions 15
    • 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
    • Collaboration Example $greeting = 'hello world'; echo $greeting; $greeting = 'hey people'; $greeting = 'hello world'; echo $greeting; print $greeting; $greeting = 'hey people'; print $greeting; 17
    • 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
    • Conflict Example $greeting = 'hello world'; echo $greeting; $greeting = 'hey people'; $greeting = 'hi universe'; echo $greeting; echo $greeting; $greeting = 'hey people'; echo $greeting; 19
    • Conflict Example greeting.php greeting.php.r365 <<<<<<< .mine $greeting = 'hello world'; $greeting = 'hi universe'; echo $greeting; ======= $greeting = 'hey people'; >>>>>>> .r366 echo $greeting; greeting.php.mine greeting.php.r366 $greeting = 'hi universe'; $greeting = 'hey people'; echo $greeting; echo $greeting; • Correct greeting.php and then let Subversion know you have resolved the conflict 20
    • Branching 21
    • 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
    • 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
    • Repository Structure • Repository layout choices • Deployment point choices • Affected by process • Dependent on product type 24
    • 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
    • Continuous Releases • Changes to branch • Branch merged to trunk • Can patch changes from branch to trunk for bug fixes • Deployment from trunk 26
    • Branch Deployment trunk version 1.1 development branch version 1.2 testing deployment! 27
    • Live Branch • Changes to branch • Branch merged to trunk • Testing performed on trunk • Changes then patched to live branch • Deployment from live branch 28
    • Live Branch Deployment trunk live branch development branch testing deployment! approved changes 29
    • 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
    • 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
    • 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
    • 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
    • SVN and Deployment • Deployment process • Deployment mechanism • Subversion • Other tools 34
    • Questions? Lorna Mitchell - lorna@ibuildings.com Ibuildings