versioning for developers

45
Michelangelo van Dam Macq Electronique 2010 Brussels, Belgium Versioning for developers

Upload: michelangelo-van-dam

Post on 17-May-2015

2.932 views

Category:

Technology


0 download

DESCRIPTION

Using a revision control system that tracks changes in source code with ways to manage your code in separate branches and tag revisions as releases is a bare minimum for developers. This presentation highlights the importance of using a version control system Subversion.

TRANSCRIPT

Page 1: Versioning for Developers

Michelangelo van DamMacq Electronique 2010 Brussels, Belgium

Versioning for developers

Page 2: Versioning for Developers

Michelangelo van Dam

• Independent Consultant

• Zend Certified Engineer (ZCE)

- PHP 4 & PHP 5

- Zend Framework• Co-Founder of PHPBenelux• Shepherd of “elephpant” herds

Page 3: Versioning for Developers

For more information, please check out our website http://www.macqel.eu

TAIL ORMAD E SO LU T IO NS

Macq électronique, manufacturer and developer, proposes you a whole series of electronic and computing-processing solutions for industry, building and road traffic.

Macq électronique has set itself two objectives which are essential for our company :

developing with competence and innovation earning the confidence of our customers

Macq électronique presents many references carried out the last few years which attest to its human and technical abilities to meet with the greatest efficiency the needs of its customers.

Page 4: Versioning for Developers

About this presentation

• Concepts of version control• Management with subversion• Life cycle of a project in subversion• Parts and structures within subversion• Advanced subversion tools• New in release 1.5

Page 5: Versioning for Developers

What is version control ?

“Revision control (also known as version control ...) is the management of multiple revisions of the same unit of information.”(source: Wikipedia:RevisionControl)

Page 6: Versioning for Developers

Versioning for developers

• version control provides- management of versions of information• code/tests• configuration files• documentation- in a structured, standardized way- with repositories• centralized (SVN, CVS)• decentralized (GIT)

Page 7: Versioning for Developers

Why need versioning ?

• enables collaboration between developers• centralized “main code” (trunk)• custom code alongside main code (branching)• eases release management (tags)• rollback to previous revisions• integration with other tools

Page 8: Versioning for Developers

Subversion (SVN)

• Subversion (http://subversion.tigris.org)• more advanced than CVS• less complex than GIT• integrates well with other tools

(trac, gforge, jira, ...)• supported by many tools

(Zend Studio, TortoiseSVN, Subversion CLI)

Page 9: Versioning for Developers

An example project in trac

Page 10: Versioning for Developers

SVN browser Zend Studio

Page 11: Versioning for Developers

Code managing with SVN

• many developers create much code• code is committed to a central repository- conflicts trigger warnings• user and groups can be defined• different versions can co-exist• access management for named and anonymous

access rights

Page 12: Versioning for Developers

Subversion authentication

• svnserve server$ svn svn://server/project/trunk• svnserve server over SSH

$ svn svn+ssh://server/project/trunk• Apache webserver

http://svn.server/project/trunk

Page 13: Versioning for Developers

Version management

• all code resides in “trunk”• code revisions are detached in “branches”• snapshots for releases are “tagged”

Page 14: Versioning for Developers

Subversion Schema

Page 15: Versioning for Developers

Putting a project into SVN

Say you’ve started project FooBar with following files:/FooBar /Foo.php /Bar.php

To put it on a Subversion repository:$ svn import -m “new project” FooBar http://svn.server/FooBar/trunk

Page 16: Versioning for Developers

Getting code from SVNA new team member needs to work on the FooBar project

He needs to get the project from Subversion

To get it from a Subversion repository:$ svn checkout http://svn.server/FooBar/trunk FooBar

This will fetch the latest revision (HEAD) from the TRUNK and creates a local FooBar directory

Page 17: Versioning for Developers

Updating code in SVNAfter a well deserved holiday, you need to continue working on the FooBar project

You need to get updates of the project from Subversion

To update your working copy from Subversion repository:$ svn update /FooBar

This will update your working copy with the latest revision (HEAD) from the TRUNK

Page 18: Versioning for Developers

Committing back to SVNYou’re working hard on FooBar and you need to commit your changes back to Subversion.

To commit changes back to Subversion repository:$ svn commit -m “Added some cool stuff”

This will commit changes in your code to the TRUNK.

Page 19: Versioning for Developers

Best practice

Update before committingUpdate after committing

Commit small development chunksCommit often

Page 20: Versioning for Developers

• a release is a snapshot of a version branch• are being deployed to server environments

(DEV, TEST, ACC, PROD, ...)• 2 common methods to release code- symlink deployment- subversion export

Release management

Page 21: Versioning for Developers

Symlink Deployment

• On production server(s):- use release folders

svn co svn://server/myproj/tags/rel-1.0 /web/myproj-rel-1.0- create symlink to it

ln -s /web/myproj-rel-1.0 /web/myproj• Pro: - simple• Contra: - renaming folders on server- enabling FollowSymlinks

Page 22: Versioning for Developers

Subversion Export

• Exporting a release from subversionsvn export http://svn.server/project/tags/release-1.0.2• Pro:- scheduled (automated) upgrades possible- no further modifications necessary• Contra:- takes longer to switch back to previous release

Page 23: Versioning for Developers

SVN life cycle

v1.0 v1.1

rel-1.1.1 rel-1.1.2

rel-1.0.1 rel-1.0.2

feature branch

bug fixTrunk

Page 24: Versioning for Developers

Trunk

• trunk is where all code resides- except custom development• has always the latest version• is not always the most stable version

Page 25: Versioning for Developers

Branch

• two kind of branches exists- feature branches- release branches

Page 26: Versioning for Developers

Feature Branches

• code that changes many things in trunk• are best put in a separate branch• maintained by their developer(s)• and merged back into trunk- after the merge, the branch is removed• when changes are done and tested

Page 27: Versioning for Developers

Release Branches

• are maintained in branches• have a long lifetime cycle (several years)• differ from each other- because of new code base, framework, language• have a common base = trunk• fixes from versions go into trunk• back port fixes go from trunk into version

Page 28: Versioning for Developers

Tags

• tags are snapshots• usually made on version branches• can also be made on “trunk”• are deployed to server environments• are used to keep track what’s happened between

releases (change log)

Page 29: Versioning for Developers

More than just versioning

• Subversion provides more features- File portability- Keyword substitution- Locking- Externals- Peg and Operative revisions- Network model- Hooks

Page 30: Versioning for Developers

File portability

• Line endings differ on different OS’s- are ignored when checking modifications• Mime-types differ from their extensions- binary and non-binary files are tested on content

Page 31: Versioning for Developers

Keyword substitution

• Only a few keywords are substituted- $Date:$ › $Date: 2008-10-22 20:00:00 +0100

(Wed, 22 Oct 2008) $- $Revision:$ › $Revision: 144 $- $Author:$ › $Author: svnusername $- $HeadUrl:$ › $HeadUrl: http://svn.test.be/trunk $- $Id:$ › $Id: file.php 148 2008-10-22 20:00:00Z

svnusername $

Page 32: Versioning for Developers

Locking

• working copy locks- exclusive right to a working copy- clears with “svn cleanup”• database locks- ensures database integrity- only admins can remove this lock

• conflicts with the purpose of revision control

Page 33: Versioning for Developers

Externals

• Externals provide an easy way to- include other internal or external projects- without having to care about their revisions• Examples:- Zend Framework as svn:externals on library path- project that includes many smaller projects

Page 34: Versioning for Developers

Peg & Operative revisions

• automated handling of- moving files- deleting and creating new files with same name• Using specific syntax- $ svn command -r OPERATIVE-REV item@PEG-

REV

Page 35: Versioning for Developers

Network model

• Can run its own svnserve- pros: no dependencies, works with ssh for extra

security- contras: need svnclient to connect• Or in combination with Apache webserver- pros: works with any http-client- contras: overkill for small projects, requires

mod_dav_svn, more difficult to set up

Page 36: Versioning for Developers

Hooks

• Hooks facilitate actions to be taken- before a commit starts (validate rights)- after a commit (send e-mail, update tracker, ...)- before or after a revision change (notifications)• Can easily be incorporated with tools- tracking tools- integration tools (Lorna Jane’s Nabaztag)- mailing and logging systems

Page 37: Versioning for Developers

Hooks execute moments

• basic commit moments:- start-commit: • runs before commit transaction started- pre-commit:• runs right before commit transaction is

promoted- post-commit:• runs after the commit transaction is finished- ...

Page 38: Versioning for Developers

Cool things w/ SVN hooksLorna Jane’s Nabaztag

Responding on SVN commits

http://www.flickr.com/photos/lornajane/2592602734/

Page 39: Versioning for Developers

Automated builds

• With SVN and Phing (PHP Build tool)- nightly checkout of code base- running tools to enhance code• PHPDocumentator (automated API docs)• PHP_CodeSniffer (checks code for standards)• PHPLint (checks code for syntax errors)• PHPUnit (unit testing for PHP)• …- creating a package (including docs, tests, reports)

Page 40: Versioning for Developers

New features in SVN v1.5

• Merge tracking (foundational)• Sparse checkouts (via new --depth option)• Interactive conflict resolution• Changelist support• Relative URLs, peg revisions in svn:externals• Cyrus SASL support for ra_svn and svnserve• ... (more on http://subversion.tigris.org/

svn_1.5_releasenotes.html)

Page 41: Versioning for Developers

Summary

• manageable file change history• better collaboration between developers• clearer release management• more than one version of same code base• easier to rollback in case of emergency

Page 42: Versioning for Developers

Recommended ReadingVersion Control with Subversion, 2nd Edition(O’Reilley Media, Inc)

by C. Michael Pilato; Ben Collins-Sussman; Brian W. Fitzpatrick

also online: http://svnbook.red-bean.com

Managing Software Development with Trac and Subversion(Packt Publishing)

by David J Murphy

Page 43: Versioning for Developers

Recommended Reading

Subversion Version Control:Using the Subversion Version Control System in Development Projects (Bruce Perens' Open Source Series)

by William Nagel

Page 44: Versioning for Developers

Credits

Wikipedia Logohttp://commons.wikimedia.org/wiki/File:Wikipedia-logo.png

Page 45: Versioning for Developers

Thank you !

Slides on Slidesharehttp://www.slideshare.net/group/macqel

Give feedback on Joind.inhttp://joind.in/1260