Application Lifecycle Management with TFS

 Mehdi Khalili
 Consultant at Readify
 Code, lead and mentor by day
 Blog and hack on OSS by night

 Blog: www.mehdi-khalili.com
 Twitter: @MehdiKhalili

 ALM
 ALM the TFS way
 Team Collections and Team Projects
 Version Control and branching
 Build Automation
 Work Item Tracking
 Team Collaboration Using Portal
 Web Access!
 Putting it all together

There may be glitches in demos due to our virtual setup

This is not a TFS only talk. We are going to talk about ALM and
software processes and methodologies

 A quick tour of our virtual environment
 Windows Server 2008
 SQL Server 2008 R2
▪ Database
▪ Reporting Services
▪ Analysis Services
 Windows SharePoint Services 3.0
 Team Foundation Server 2010
 Visual Studio 2010 Premium

 “continuous process of managing the life of
an application”
 Increases productivity
 Improves quality
 Accelerates development through simplified
integration
 Cuts maintenance time
 Maximizes investments
 Increases flexibility
 …

 Build management
 Release/deployment
 Testing
 Requirements management
 Work item management
 Project management
 Change management
 Configuration management
 ….

The most integrated ALM solution
in .Net land

 A quick tour of the Administration Console
 Application Tier
 Team Project Collections
▪ Team Projects
▪ SharePoint portal
▪ Reporting
 Build Configurations
▪ Build Controllers
▪ Build Agents

 The basic unit of recovery
 One database per collection
 Benefits
 Scalability: load balance
 Backup and recovery
 Security isolation
 Information sharing
 Organizational/team structure

 The largest unit of work associated with
developing a single product or product line

 Each collection can have many team projects

 Creating Team Projects is time consuming
 Per Team Project you will get
 Milestones and release schedules
 Areas and Iterations
 Version Control Settings
 ALM methodology
 Process Template and its customization
 Portal

 CMMI
 Agile
 Scrum

Work Item Comparison
Agile Scrum

Bug Bug

Issue Impediment

User Story Product Backlog Item

Task Task

N/A Sprint

User Story vs. PBI
User Story Product Backlog Item

Title Title

Description Description

Rank Backlog Priority

Story Points Effort

Business Value Business Value

Acceptance Criteria Acceptance Criteria

 Customize a project’s template
 Customize Project Template

 A journal of changes to your code
 All actions are irreversible: if you make a
mistake you can only reverse it by
compensating actions (well, except in git which allows you
to rewrite the history – oh yeah)

 Atomic check-ins
 Branching and merging
 Shelving
 Labeling
 Concurrent check-outs
 Check-in policies
 Association of check-ins with work items

 Add a project to source control
 Workspaces
 Get a project
 Get latest
 Get specific
 Check-in
 Check-out and Lock!!!
 Undo changes
 Shelve-sets: shelving and unshelving
 Move
 …and Source Control File Types

 Check-out settings
 Bringing VSS annoyance to TFS!!
 Check-in policy
 Some useful policies
 And some are unnecessary and annoying
 Check-in notes

The Dark Side
of
Version Control!

 Feature branch
 Dev branch
 Release branch
 Hotfix branch

 Integration isolation
 Technology specific branch

 Create a branch
 Make some changes on the branch
 Merge changes back

 Make some changes on the branch
 Make some changes on the mainline
 Merge changes and resolve the conflict

 “No Branching”, Says Me

 But if you REALLY need branching at least do it on demand
 And then do your best to remove the demand ;-)

 Create a label on the release
 Do NOT create a branch
 If you need to fix some bugs on the release
branch off the label

 Do NOT forget to merge your changes back

 Chrome with hundreds of millions of users is
released every six weeks

 Chrome Canary is released once a day

 Flickr with hundreds of millions of users
deploys to production 10 times a day

 You need to maintain workable Mainline
 You want to check-in frequently
 Conflicting needs
 Feature branching seems like the solution

From Feature Branching By Martin Fowler

 Make your features small
 Have very few features in progress
 Do not create developer silos

 Branching is painful. You may reduce the
pain; but it is always going to hurt

 Avoid branching using
 Smaller features
 Shorter sprints
 Feature Toggle
 Branch By Abstraction

 … but sometimes you just HAVE to create a
branch. That is ok because it should not
happen often

 Integrate your work frequently
 Everyone checks into Mainline on daily basis
 Every commit should be built
 Builds should include test runs
 Keep the build fast
 Keep your tests fast

 Use CI to drive your Automated Deployment

 With or without branches, please
continuously integrate back and forward
 And do not forget: Mainline is the king!

From Feature Branching By Martin Fowler

 AKA baseless merge in TFS land

 Only doable through command prompt
 This is not a good ideausually

 And we never talked about it – alright?!

 Offline Mode
 Source History
 Code Annotation
 Diff tools
 Comparing files
 Comparing folders
 Merge tools
 Two way merge
 Three way merge

This is an important part of
Continuous Integration

 Several triggers:
 Manual
 CI
 Rolling Builds
 Gated Check-In
 Scheduled
 From MSBuild in 2008 to WF in 2010
 Some are happy and some like me are sad pandas

 Manual: most useful for deployment builds
 CI: Good for CI
 Rolling Build: Useful when you have a big
team and devs check-in very frequently
 Gated Check-In: Useful for junior teams and
for your Mainline if you have many branches
 Schedule: useful for functional tests, nightly
builds, …

 Install TFS on your agent machine
 Set it up as an agent for the build controller
 Give your agents good names
 Optionally give it some tags
 You can use tags in your build definition
 Or when you queue the build

 You can see a list of controllers and agents
from team explorer

 You can queue
 The latest code
 A shelveset
 A changeset
 A label

 Test result
 Broken test could break the build
 Keeping a build result around
 Build Log
 MSBuild Log
 Drop folder
 Build folder

 Get (late) notifications on builds
 Desktop notification from TFS
 Do not rely on it; but having it could help

Remember Chrome and Flickr

If you want to win you should do the same

Short Happy
Continuous Feedback
Integration Cycle Customer

Continuous Continuous
Testing Delivery

 No matter how big your application is, if your
deployment takes more than a minute to
trigger you are doing it wrong

 Some cool tools:
 MSDeploy
 TFSDeployer

 You need to apply database transformation
as part of your push-button deployment

 Some cool tools
 MigratorDotNet
 DBUP

 Different environments have different
settings
 To create push-button deployment you need
to easily apply config transformations

 Some cool tools
 CodeAssassin.ConfigTransform
 SlowCheetah

 Integrated work item tracking system
 Integration with Version Control
 Requirements, tasks, bugs, issues, test cases
 Extensible:
 Create your custom fields
 Change the layout
 Available states
 State transitions

 Create a sprint
 Create iterations and areas
 Create Product Backlog Item/Story
 Create tasks and subtasks
 Create bugs
 Create impediments
 Check-in code against a backlog item
 Create custom queries

 Editing multiple entries at once
 Populating your backlog

 Backlog is a living creature!!
 If your backlog is not growing your product is
dead
 Backlog MUST be always prioritized
 Do not forget to groom your backlog
 The Team should help PO groom the backlog
 Prioritize your backlog
 Backlog MUST be always prioritized

Customer Preferences
 Attractive
 One-Dimensional
 Must-Be
 Indifferent
 Reverse

 Deny is THE king
 And then there are administrators
▪ Project Collection Administrators
▪ Project Administrators
▪ Team Foundation Administrators
 Allow is the king in the absence of Deny
 Unset means denied unless stated otherwise
 This is where inheritance shines

 Administer warehouse
 Create team project collection
 Delete team project collection
 Edit instance-level information
 Make requests on behalf of others
 Trigger Events
 Use full Web Access features
 View instance-level information

 SharePoint Web Application Services
 Team Foundation Administrators
 Team Foundation Service Accounts
 Team Foundation Valid Users
 Work Item Only View Users

 Administer shelved changes
 Administer workspaces
 Create a workspace
 Create new projects
 Delete team project
 Manage process template
 Manage build resources
 Delete team project collection
 ….

 Project Collection Administrators
 Project Collection Service Accounts
 Project Collection Build Administrators
 Project Collection Build Service Accounts
 Project Collection Valid Users
 Collection Proxy Service Accounts
 Project Collection Test Service Accounts

 Project Administrators
 Contributors
 Readers
 Builders

 Permission Levels:
 Project
 Build
 Work Item Query
 Areas
 Iterations
 Version Control
 And each has very granular permissions

 Create different AD groups for different roles
 TFS has to be granular to suit every need
 Do not over specify – a few groups would
usually suffice
 Do not lock it in: adapt as need arises

 Project documents and requirements
 Process Guidance
 Dashboard with reports about ongoing things
 Wiki

 Some versioning goodness

 Announcements
 Contacts
 Discussion Boards
 Out of TFS Tasks
 Surveys
 ….

 RSS subscriptions
 Alerts

 Environment Lists: Name, status, URLs,
current release info, access details if need be
 Active Risks
 Sprint info: sprint No., goal, start and end
dates, daily stand-up location and time,
review location and time
 Project Glossary
 Important Dates
 Contacts

 Create/Edit Work Items and Work Item
Queries
 Create/Edit Areas and Iterations
 Read-only access to Version Control
 Access to Team Build
 A Work Item Only View (doesn't require CAL)

 Your work items (or any work item) changes
 Or a work item is assigned to you
 Or a new work item is created
 Build Quality Changes
 Or a build completes
 Or it fails
 Anything is checked in
 Or there is a check-in on a specific file
 Or a folder
 Or a file extension
 Or when a check-in policy is overridden

 Roles  Ceremonies
 Product Owner  Sprint planning
 ScrumMaster  Daily standup
 The Team  Sprint review
 Sprint retrospective

 Documents
 Product backlog
 Sprint backlog
 Burndown charts

 There is no silver bullet - NEVER
 … and TFS is no exception
 A good process succeeds regardless of tools
 To succeed we should
 Be transparent
 Inspect
 Adapt
 Get as much feedback as frequently as possible
 … and the tool comes next

 git-tfs and posh-git
 Team Foundation Sidekicks
 Team Foundation Power Tools
 Telerik’s TFS Project Dashboard
 TFS Integration Tools
 TFS Administration Tools

 Just search for them

 TFS Permissions:
http://msdn.microsoft.com/en-us/library/ms252587(v=vs.100).aspx
 VS TFS Branching Guidance:
http://vsarbranchingguide.codeplex.com/
 Continuous Integration:
http://martinfowler.com/articles/continuousIntegration.html
 Feature Branching:
http://martinfowler.com/bliki/FeatureBranch.html

 Branch By Abstraction:
http://continuousdelivery.com/2011/05/make-large-scale-
changes-incrementally-with-branch-by-abstraction/
 Feature Toggle:
http://martinfowler.com/bliki/FeatureToggle.html
 Mitigate your merge issues:
http://www.mehdi-khalili.com/mitigate-your-merge-issues

 MSDeploy:
http://www.hanselman.com/blog/WebDeploymentMadeAw
esomeIfYoureUsingXCopyYoureDoingItWrong.aspxhttp://ch
annel9.msdn.com/events/mix
 TFSDeployer:
http://tfsdeployer.codeplex.com/
 TFS Sidekicks:
http://www.attrice.info/cm/tfs/
 App and Web Config Transformation
http://www.mehdi-khalili.com/transform-app-config-and-web-config

 Team Foundation Power Tools:
http://visualstudiogallery.msdn.microsoft.com/c255a1e
4-04ba-4f68-8f4e-cd473d6b971f
 Telerik’s TFS project dashboard:
http://www.telerik.com/agile-project-management-
tools/tfs.aspx
 TFS Integration Tools:
http://visualstudiogallery.msdn.microsoft.com/eb77e739-
c98c-4e36-9ead-fa115b27fefe
 TFS Administrations Tools:
http://tfsadmin.codeplex.com

Application Lifecycle Management with TFS

More Related Content

What's hot

Similar to Application Lifecycle Management with TFS

Recently uploaded

Application Lifecycle Management with TFS

Editor's Notes