release mgmt with tfs

7/24/2019 Release Mgmt With TFS

1/50

Release Management/SCM

with TFSScott Colestock

Presented by


2/50

About me -

Consulting independently in the BizTalk2004/2006 space for about 3 years

Blog !!!"traceofthought"net

#ecently focused on $%T%/T&%'speaking/!riting/production rollouts(
http://www.traceofthought.net/http://www.traceofthought.net/


3/50

Agenda

Branching ) *erging

Mechanics within TFS

Strategies

+o! does Tea, Build help !ith %C*-

Carrying through to physical en.iron,ents

TFS Deployer


4/50

Software Configuration Management

The process of identifying and selecting allthe ele,ents of a soft!are syste, thatcreate the correct and cohesi.e set atdened points in ti,e

Not unlike managing bill-of-materials for a highlycomplex manufactured product

1arge topic !ere focused 'pri,arily( onbranching ) ,erging strategies

5oor %C* leads to de.elop,ent testingand operational ine7ciencies


5/50

Branching Mechanics in TFS

T&% i,ple,ents 8path space branching9 '.s"8.ersion space9(

Similar to subersion

!"S#others hide the branch$

Branching in T&% is essentially like doing a 8deepcopy9 of a folder on your local dri.e

%ut branch &parent' is presered (where in the tree you

branched from)

*riginating changeset is presered

+bility to selectiely merge parent changesets into the branch


6/50

Branching Mechanics in TFS

5ath space branching ,eans you see thebranch folder directly in the %ource Control:;plorer easy to na.igate retrie.e andestablish permissionsper branch

T&% i,ple,ents an i,,ediate branching,odel rather than deferred 'i"e" branchonchange(

More meta-data created at the point of branchoperation (though ,ust one copy of underlying files

until changed in branch)

+ bit more useable contents of branch are clear


7/50

Branching Mechanics

e.9 or8*ain9 folder not at your Tea,

5ro=ects source root

Branch operation asks you tospecify a 8branch target9 alocation in the source control

hierarchy !here the branchshould li.e


8/50

Branching Mechanics

*ost of the ti,e this !ill be apeer e"g" ?/@rder%yste,/A'or !hate.er the purpose of thebranch is(

eep clear on the diDerencesbet!een branch parent/childrelationships and the physicalstructure you obser.e on disk

and in source controlrepository


9/50

Branching Mechanics

Branch operations result in a setof pending changes 'of type8branch9( !hich ,ust bechecked in before branch is,ade real

Branching can cross TFSprojects as well

seful for sharing code across pro,ectswhen you still desire to build#unit-testindependently


10/50

Branching Thoughts

*ental ,odel Eust like workspaces pro.ideisolation for a gi.en de.eloper branchespro.ide isolation for a group of de.elopers

@nly branch if you ha.e to and at thepoint in ti,e reFuired

%ranches can happen &after the fact' ia branch-

from-label. branch-from-changeset. etc/

(0ike at the point in time you need to create ahotfix$)


11/50

Branching Thoughts

l!ays ask ont use branching to ,aintain diDerentconfgurationsof the sa,e product" >o this atbuild ti,e packaging ti,e or deploy,ent ti,eetc"


12/50

Simplest Branching Model: None

eep in ,ind TFS Team %uilds are labeled automatically. or you can apply

your own label

2ou can branch-by-label at a later point in time if you need to$

2ou can modify the contents of a label for small-scale changes

Hf your tea, ,o.es for!ard togetherand youha.e a single release point 'e"g" your !eb site(you ,ay ne.er need to branch

Do you need to actually do serice releases#patches3

!r do "ou #ust do another $point% release each month or so&

Do people work &ahead' on items you don4t intend to release

in your next drop3


13/50

'(abel )etour*


14/50

Branch b" (abel


15/50

(abel Thoughts

1abels allo! you to apply a ,arker to the current 'or past(state of a le or folder

Isually used to denote a ,ilestone or release

Jou can apply ,ultiple labels to a .ersion of a le orfolder

Contents of a label can be edited after the fact 'but no.ersion history of the label is ,aintained(

Tea, Build auto,atically assigns a label to the set of lesassociated !ith each build that it creates"

Tri.ia K1abel scope is a path !ithin source control underneath !hich no other labels !ith the sa,e na,e canbe created

5hen you use Source !ontrol 6xplorer. scope 7 pro,ect root


16/50

+isuali,ing (abels The 8contents9 of a label

is a set of changesets The minimum number of

changesets needed to describethe state

ll that ,atters is the8aerial .ie!9

The fact that otherchangesets !erein.ol.ed in reaching thelabeled state is irrele.ant

1abel can be describedby the content of thechangesets 8.isible9 fro,the top looking do!n

Label: 1.05 Release


17/50

(abel Mechanics Hn %ource Control :;plorer rightclick at appropriate

le.el and select 81abel9 to apply a label To &latest'

*r by date

*r by changeset

(*r by label %uild &De Debug89::;:' is also "ersion 9/?)

To nd/delete/edit use &ile%ource Control1abel&ind1abel 6dit allows you to choose additional &participants' in the label or later

ersions of existing participants

Ise http//shurl"org/tfskicksfor ad.anced label features

0abel comparison 0abel changeset contents (union of all participant changesets)

0abel work items
http://shurl.org/tfskickshttp://shurl.org/tfskicks


18/50

Branching Models at ./... ft

1ots of religious debateL But ,any !ould say Deelop most new code on the &trunk'

Aka $main line%/ aka $de0elopment branch%

%ranch per feature and#or per team if absolutely re@uired

%ranch to stabiliAe and release &eature Branch

1solate work on new or experimental features that might cause

instability to the rest of the pro,ect/

1solate work on interface changes that will cause instability for

the rest of the pro,ect/


19/50

Branching Models at ./... ft

Tea, Branch

1solate sub teams so they can work without being sub,ect to

breaking changes from other teams/

1solate sub teams so they can work towards uni@ue milestones/

Team branches often hae feature branches beneath them/

#elease Branch

%ranch for builds that will re@uire you to perform ongoing

serice#maintenance (sub-branch for hotfixes)

%ranch to pursue#stabiliAe multiple releases in parallel


20/50

Considerations in Branching

Consider structuring branch trees so you onlyneed to ,erge up/do!n the branch hierarchy notacross +oids need for &baseless merge' (tf #merge baseless $)

Bemember that branch hierarchy likely doesn4t match repository

and file system layout in terms of the &tree' Merging a change back &up' to main line and &down' to another

branch re@uires care

Hf you branch too deeply '*ain M Tea, M &eatureM :;peri,ental !ork( you !ill introduce latency

*erges reFuire conGict resolution and bad ,ergedecisions can happen so the resulting build ,ustbe tested thoroughly


21/50

A few branching use cases1


22/50

Branching to aid nightl" build stabilit"1

>e. 'aka trunk/,ain( branch for acti.e checkins

&1t compiled locally and on build serer'

+ll deelopers hae read#write

!ontinuous builds (!1) should happen here

se for @uick feedback C feature tests

Hntegration branch for integration &1t passed build erification tests'

+ll deelopers hae read limited people hae read#write

*nly merge non-breaking changes from &De'

se as basis for perf. security. integration tests (might call &Test'

branch for this reason) Nightly builds

!an use as basis for production branches


23/50

Branching to stabili,e new feature

>e. branch ,ay ha.e child branches for eachfeature reFuiring acti.e o.erlapping ) isolatedde.elop,ent

De

Feature

Feature 2

Feature 3

@nly 8!orth it9 if your features freFuently collide

'broken builds and/or freFuent conGicts( and the cost of merging conflicts in real time is higher than the

cost of merging conflicts between branchesE


24/50

Branching for independent teams1

>e. branch ,ay ha.e child branches for eachteamthat reFuires acti.e o.erlapping ) isolatedde.elop,ent

De

Team

Team 2

Team 3

@nly 8!orth it9 if your tea,s freFuently collide'broken builds and/or freFuent conGicts( and

the cost of merging conflicts in real time is higher than thecost of merging conflicts between branchesE

Sometimes true for geographically distributed teams where

communication oerhead is high


25/50

Branching to isolate changes in e4ternal

dependencies1 8>e.9 branch ,ay ha.e a child branch

!here changes to third party libraries 'or

internal fra,e!orks( are absorbed )tested to ensure no breaking changes

*erge to >e./*ain can occur once testingco,plete


26/50

Branching to support a release

>e. branch e.eryone !orks here if tea, ,arching together Hntegration/Test ,erge rom>e. and to5roduction fro, here

'al!ays the basis for production branch not last release(

5roduction branches &Belease ='

5ot fi4es are likel" labels on the release branch/ not new branches1

&Belease 9'

Hf diDerent tea,s are pursuing !ork on diDerent releases andthey reFuire isolation tea, ,ay !ork directly in releasebranches to pursue stabilization or ser.ice/,aintenance !ork Fixes can be merged back to De (aka trunk)

%ut carefully The fix might not apply directlyE

$"ne;t !ork can happen in >e. branch once the release branchhas been created" Can be shel.ed te,porarily until thathappens"


27/50

Branching to support a release

Branch ,odels like this are ter,ed8*ainline de.elop,ent9 or 8branch bypurpose9

Note &i;ing a bug in #elease O that also

e;ists in #elease 2 reFuires careful thought !an fix at earliest point in time (say Belease =). merge

back to trunk. then merge forward to Belease 9

%ut this includes risk of taking unwanted main line

change into Belease 9

May wish to attempt baseless merge instead in some

circumstances


28/50

Alternate branching method

Challenges to using each release branch as basis for ne;t

release 'as opposed to using ,ainline( Not intuitie for deelopers to point their enironment to differentbranches (though s/net makes this easier)

Difficult to work on multiple releases at once een more difficult towork on future release

6ri0ate branch will re7uire baseless merge

6asier to work in one branch. knowing work is promoted to

appropriate branch d.antage is that bug ; in old release only has to be

propagated for!ard 'not up to trunk ) back do!n oracross(

1ots of debate on !hich ,odel is better


29/50

Branching to model promotions1

Branch per en.iron,ent >e. A %tage5roduction

1abels ,ark release points branchbylabel later if you need to for special

purposeThis ,ethod generally acco,panied by

negrained changesets !ith clear !orkite, associations

s you ,erge fro, >e. to A 'etc"( youcan handpick changesets *r by work item using Team!M


30/50

Team Foundation 6romotion Modeling'Branches of .arying Fuality(

foo8csfoo8cs

bar8csbar8cs

$//Dev$//Dev

$//Test$//Test

$//Prod$//Prod1818

1818

foo8csfoo8cs

bar8csbar8cs 1313

1313

foo8csfoo8cs

bar8csbar8cs 99

99

11

1!1!

1"1"

1#1#

11

1"1"

!!

1919

!!!!

!1!1

!"!"

!"!"

1%1%

1%1%

!3!3

!3!3

!!

!!

!#!#

!#!#

!%!%

!%!%

After 12: Branch to test = 13

After 16: Merge latest to test = 1

After 1: Branch to !rod = 1"

After 22: Merge 21# 22 to test = 23

After 23: Merge latest to !rod = 2$

After 25: Merge latest to test=26

After 26: Merge latest to !rod=2


31/50

Merging Mechanics in TFS


32/50

Merging

Can ,erge by Selecting indiidual changeset(s)$

9seful for handpicking bug fi4es or changes to merge

Closed bugs 'work items* will tell "ou which changesets are

associated fi4change Must be a contiguous range of changes for a givenmerge

operation 'ouch*

;eep "our changesets fine-grained epending on !hich CH solution you use you can

enact dependency replication as part of build TFS 1ntegrator will do this$

(*r use MSDN sample)


37/50

SCM Mileage from Team Build Hf you ha.e a tea, build type per branch

nd you ha.e continuous integration conguredfor each branch

Then e.ery ,erge bet!een branches '>e.MTestor

&eaturePM*ain( !ill trigger a build

The 8branch build9 can in.ol.e unit tests that areassessing 'in part( !hether the ,erge operationproduced good results

"aluable. since merges often error prone


38/50

C= for TFS 2..>


39/50

C= for TFS 2..?


40/50

Agenda

Branching ) *erging

Mechanics within TFS

Strategies

+o! does Tea, Build help !ith %C*-

Carrying through to physicalenvironments

TFS Deployer


41/50

SCM )efinition @e0isited

8The process of identifying and selectingall the ele,ents of a soft!are syste, thatcreate the correct and cohesi.e set atdened points in ti,e"9

@nce you ha.e a branching/,ergingstrategy in place and a corresponding setof builds that occur based on thosebranches

Carry it through to a set of auto,ateddeploy,ents to corresponding physicalen.iron,entsL


42/50

TFS )eplo"er '@eadif"*

%ee http//shurl"org/tfsdeployer Hnstalled as an agent on ser.ers that you ,ust

deploy to De enironment. Test enironment$Groduction3

1istens to build Fuality change e.ents

%uild @uality is edited within build store in s/net %uild store notifies eent serice. which lets all subscribers

(including TFS Deployer) know about @uality change


43/50


44/50

TFS )eplo"er '@eadif"*

T&% >eployer uses deploy,ent ,apping le'checked into subfolder of tea, build type( todeter,ine !hat 'if any( action to take

Deployment file might indicate that a deployment for test

serers should be kicked off when build @uality transitions from

&De +ccepted' to &Test Staging'

>eploy,ent *apping le associates sererstoactionsbased on build Fuality transitions for agi.en build

!an deploy to a farm by haing multiple serers listed +ctions are powershell scripts


45/50


46/50

Team Build and $Build ualit"%

Build Auality na,es in Tea, Build arecusto,izable so choose to ,atch yourprocessL

*itch >enny '#eadify( suggests

nexamined

Deelopment Staging#+ccepted#Be,ected

Test Staging#+ccepted#Be,ected

Groduction Staging#+ccepted#Be,ectedTransitions can be secured


47/50

S"nergies from the whole1


48/50

4tending release management to database

artifacts: +isual Studio for )atabase 6ros

>atabase #efactoring

%che,a co,parison

>ata generation tools

>atabase unit testing tools

>atabase pro=ects +bility to harest all schema ob,ects

from existing scripts or lie schema

Triggers. functions. security elements.sprocs. tables. iew. constraints.

indexes. keys. triggers. DT$ House in a single pro,ect with both

&script centric' and &schemacentric' iews


49/50

+isual Studio for )atabase 6ros ey idea is to bring database de.elop,ent !ork into

the standard de.elop,ent lifecycle "ersion control (branching#merging) !ollaboration with team nit tests

Hdeal :ach tea, ,e,ber has local copy of database

!here changes to sprocs etc" ,ade in isolation andthen unit tested Co,,unication of sche,a/sproc changes to tea, and

propagation through en.iron,ents begins !ith checkinL

8Building9 a database pro=ect is an operation that isrelatie to a target enironment +nd$it generates the correct update script for you !ustomiAation (and pre#post scripts) aailable for cautious D%+s once

you are targeting stage#production


50/50

Thanks -

release mgmt with tfs

Documents