Deployment With Subversion - Lorna Mitchell
Upcoming SlideShare
Loading in...5
×
 

Deployment With Subversion - Lorna Mitchell

on

  • 10,065 views

 

Statistics

Views

Total Views
10,065
Views on SlideShare
10,000
Embed Views
65

Actions

Likes
10
Downloads
144
Comments
0

5 Embeds 65

http://www.phpconference.nl 25
http://www.slideshare.net 24
http://blog.feryn.eu 8
http://www.scriptorama.nl 7
http://admin.totalmarketing.com 1

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

Deployment With Subversion - Lorna Mitchell Deployment With Subversion - Lorna Mitchell 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