TFS Version Control tips and practices for developers version control tips and tricks... ·...

transcript

TFS Version Control tips and

practices for developers2014

SharePointUser

Experience

Data &

Business

Intelligence

Agile & Lean

ConsultingVisual Studio Cloud Services

Application

Lifecycle

Management

Custom

Development

World-Class Solutions for World-Class Organizations

Ideas transformed into reality through technology.

Imaginet powers North America’s top organizations

application lifecycle managementImaginet ALM Adoption Framework

Industry-wide demand for improved software

delivery processes / frameworks to be used

across the Enterprise

Imaginet ALM Adoption Services is proven

approach with concrete phases and objectives

Embodies the patterns that have proven most

successful in increasing team and organization

maturity

Who am I?Senior ALM Consultant Imaginet

ALM MVP (9 years)

ALM UG Leader (Montreal 5 years)

Agenda

• TFS tour

• Version control operations

• Branching and merging

• Shared Components

• Deployments

Team Foundation Server

Version Control operations

• Workspace

• Get Latest / Specific Versions /Check-out / Check-in

• What happens when I do a check-in?

• How should I use version control properly?

• Pending changes

• Check-in policies

• Shelves

• Changeset

• RollBack

What is version control?

• Central repository to manage project components

• You make Workspace in order to work with those components

until they are ready to check-in.

• A working copy of you code is into that workspace

• Supports operations like Add, Check-in, Check-out and history

• Ability to Branch and Merge componants

• All version control operations are atomic and creates Changesets

• The default work mode is shared extract of files

Choices with TFS

• Either TFSVC or Git

• Chosen at project create time

• Can’t be changed after

• TFSVC more adoption, more feature complete

• Git gradual adoption, limited features, can use open source

options since it’s the full Git implementation

• Tonight we’ll focus on TFSVC

Distributed version control system (DVCS) and Git

Version control operations

How to create a workspace?

Why should we create multiple workspaces

• Task separations

• Code verification

• Fix bugs

• R&D

Server workspaces

VC Repository$/xxxx

Dev 2 Workspace$/xxxx/yy

Server

Client

C:\WS\xxxx\yy\a.cs...

D:\xxxx\yy\a.cs...

Dev1 Workspace$/xxxx/yy

Server workspaces (what not to do…)

VC Repository$/xxxx

Server

Client

C:\WS\xxxx\yy\a.cs...

Dev1 Workspace$/xxxx/yy

Windows explorer Delete

New workspace type: Local

• No locks on files (R/W)

• Can use other tools to manage files

• Can work offline more easily

• .tfignore to ignore certain files in workspace

How to set a local workspace?

Local workspaces

What happens when you check-in to TFS

12V5912

Changeset 12

WorkItem 158

Validate

Policies 1

Checkin Policy

Engine

rk Ite

Commit

Changes

Checkin Event

Update

Work Items

Checkin Mail

Artifact

Workspace

Efficient storate in TFS VC

“The Deltafier”

File Cache

File Store

Compression + Delta Storage ≈ 70% Space Savings!

Get foo.bmp;12

9 12 15 12

Commitfoo.bmp bar.vb

Check-in

.NET Compression (GZip)

How should I use version control properly?

• Get Latest code you want to work on(GL)

• Compile and execute unit tests (if you have any) (CT)

• Check-out (CO) – Don’t do get latest until way later

• Edit– Edit the code (ED)

– Compile and execute unit tests (if you have any) (CT)

– Repeat until done (No GL)

• Get Latest Code (GL) – Bring changes from others into our workspace.– Merge if necessary

• Compile and execute unit tests (if you have any) (CT)

• Check-in (CI)

Concept: Pending Changes

Concept: Check-in policy

Concept: Shelves

Concept: Changeset

Concept: Rollbacks

How to change your compare tool

Version Control

Trifecta…

Branch

Builds

Environments

Branch and merge

Branching and Merging

• Why should we use branches

• The different branching models

• Where do we fix bugs?

• Branch visualization

• Common components

• Multi-Clients

Why should we use branches

• It’s a solution for managing parallel development

• It’s a solution to help work on features or bug fixes separately

from the main codebase

• It’s a solution to isolate and stabilize code

• Merging is a mechanism to reintegrate code that was previously

isolated and refactored

The different isolation mechanisms

Version

• Version changes are isolated one from another

Features

• Experimental and large changes are isolated from the mainline to avoid big disruption

• Isolate team so they don’t interfere between one another

Integration

• Large merge are isolated from the rest of the mainline to avoid disruption.

No branching

Simple Branching

The model I use

Standard branching

Branching per features

Staircase branching

Multi-customers (version) to maintain

• Usual for ISV that needs to maintain the « same » application for

multiple customers

• We try and maintain a base version and then « copy » it. Does

that work for you?

• How do we add features to the base that we want to share to

multiple but not necessarily all our customers

• We branch from MAIN to MAIN between customers (or version)

• We then use the standard model to start starting from the new MAIN in client 1

• Try and start from the BASE unless your new customer is closer to and existing modified customers

Concept: Branch visualisation

Concept: Branches are bidirectional

Bug fixes - Simple Branching

Where do we fix bugs?

Where do we fix bugs? (hotfix)

Concept: Merging

Concept: Conflits

Concept: Track Changeset

Concept: Merges are unidirectionnal

There are costs to using branches• Merging suggests efforts, you need more

expertise and the necessary skills to resolve potential conflicts and to fix bugs resulting from the merge

• Merging add risk of losing fixes when wrong decisions are made at merge time.

Latency• The time it takes to move changes between

branches

• Latency depends on…

– Merge frequency

– Depth vs. breadth

– Merge criterias

Branching and merging

Dependencies

Typical scenario 1

• “lib” repository in you version control structure from which you

reference you common components

– Pros

• Only one location to find common components in you project structure

– Cons

• When a common component is changed all application that reference it are

potentially affected and should be retested.

Typical scenario 2

• 3rd party repository (might be another project) which we

“branch” into are other projects

– Pro

• Only one location of your common components for multiple projects

– Cons

• Difficult to know which version we have in which projects

• What is Nuget?

– Nuget is a Visual Studio Extension that lets us add, update or delete

common libraries (can be our own) into projects that use .NET

• Why use Nuget to manage common components

– All the infrastructrure is in place in Visual Studio to deploy and update

– Need to write a few PowerShell scripts to integrate with Team Build.

How does it work

Internal Nuget

Server or share

Common components builds

Install in a branch of our projects

Trifecta…

Branch

Builds

Environments

Builds

Concept: Build Triggers

Concepts: Gated Check-in

Concepts: Build workspace

Concepts: Index and symbols

Trifecta…

Branch

Builds

Environments

Branch Environment!

Typical environments

Where do we deploy?

How do we “Tag” builds to environments

Build web access

One Build, Many Stages

DEV QAINT PRODTeam

FoundationServer

Release Management Architecture

RM ClientRM Web

QARM Server

Release information

Satellite components

• The power tools

• The web access

• The security

The powers tools

The web access

Concept: Security• Branches

• Directories

• Files

TFS Version Control tips and practices for developers version control tips and tricks... ·...

Documents