Category Archives: TFS

Developing and Deploying with Branches

13 October 2016 bryan Leave a comment

Introduction
Coding in master/trunk “branches”
Branching Workflow
Further Reading: Branching with Beanstalk

Introduction

Getting started with Version Control can be an eye-opening experience. You may have already said to yourself, “How did I work without this?”. Now that you’ve got the basics of Version Control down, you want to start getting really productive by continuing to improve your workflow. Your next step is learning to code in branches.

Coding in branches is a simple practice that keeps you and your work more organised. Branches let you easily maintain your “in-progress” work separately from your completed, tested, and stable code. Not only is this an effective way to collaborate with others, but it will also allow you to automate the deployment of updates, when needed and fixes to your servers.

Coding in master/trunk “branches”

Even if you don’t know how to use branching in your development process, you’ve already been using a branch just by committing your code to version control. In all major version control systems, each repository contains at least one branch by default, your working branch:

in Subversion this is a folder called trunk,
in Git this is a branch called master.

Without configuring anything, your first commit to any repository will be made to this working branch.

Each version control system has a different approach to creating, merging, and deleting branches. We’ll be focusing on overall development process, and suggest that you refer to the documentation of your preferred VCS for specific details about commands:

Branching Workflow

Using branches can seem complicated without some guidance. We’re going to help you by focusing on two specific uses for branches and the benefits of having them in your workflow.

Benefits of Branches: Building Features & Fixing Bugs

Most coding falls into one of these two categories: you’re either building new features or fixing bugs in an existing codebase. A problem occurs when those two things need to be happen at the same time.

Imagine that you’ve recently launched big Feature X. Things are going well at first, so you move on to start the next task on your to-do list, awesome Feature Y. You start coding and committing changes to your repository, but along the way discover a problem with big Feature X that you need to fix right away. What do you do?

If all of your work is being done in the default working branch of your repository, you’ll need to figure out how to save the work you’ve done so far on Feature Y, revert your repository to the state it was in when you deployed Feature X, make your fix, and then re-introduce your work from Feature Y. This is messy, and you could potentially lose some of your work or introduce new bugs.

Instead, you should be doing all of your work in a feature or bug-fix branches and let the VCS do the hard work for you. You would branch your repository from the point where Feature X was deployed, creating an alternate working copy for you to do new work on. Your Feature Y branch includes the entire repository’s history and code, but a separate history “starts” from the moment the branch is created. This allows you to work on the Feature Y branch, committing to your hearts content, without disturbing the code that you deployed to release Feature X.

Only once the feature is tested and complete, ready for deployment, you can merge that branch back into your main working branch.

This also means you can switch between a feature branch to the default working branch any time to create new branches from that point – like the bug-fix that you need to make. After switching back to the working branch, you would create a bug-fix branch. Working on the bug-fix in its own branch might not seem necessary if the fix is small, but following this practice will help you avoid situations where small bug-fixes turn into bigger bug-fixes, potentially leaving your working branch in a messy state.

Best Practices with Feature & Bug Branches

Try to avoid committing unfinished work to your repository’s default working branch.
Create a branch any time you begin non-trivial work including features and complex bug-fixes.
Don’t forget to delete feature branches once they were merged into stable branch. This will keep your repository clean.

Benefits of Branching: Server Environment Branches

Another reason to use version control is so that you can use your repository as the source to deploy code to your servers. Much like feature and bug-fix branches, environment branches make it easy for you to separate your in-progress code from your stable code. Using environment branches and deploying from them means you will always know exactly what code is running on your servers in each of your environments.

We’ve been talking about your “default working branch” – but you can also think of this as your development environment branch. It’s a good idea to keep this branch clean – this is easily done by using feature and bug-fix branches and only merging them back to your development branch once they are tested. In other words, at any point in time your development branch should contain only stable code. Therefore, we will be using the name “stable” from now on in this guide to refer to this branch.

Using Production and Staging Branches

In addition to your development environment, you’re likely to have at least one other environment:production, where your website or application actually runs. Having a production environment branch and making that the only source of code that goes to production ensures that you have a snapshot of what is on your production server at any time, and a granular history of what’s been added to production and when.

In most cases you will have a staging environment as well, where your team or clients can review changes together. Having a staging environment branch will help you keep that environment with the same benefits as a production branch.

Diff Branches for Easy Code Review & Release Notes

When your development environment has been updated with features and bug-fixes that are tested, you can use your VCS to do a diff between your stable branch and staging branch to see what would be deployed that’s not currently on staging. This is a great opportunity to look for low quality or incomplete code, debug code, and other development leftovers that shouldn’t be deployed. This diff can also be helpful in writing your release notes.

Never Merge to Environment Branches Without Deploying

In order to keep your environment branches in sync with the environments, it’s a best practice to only execute a merge into an environment branch at the time you intend to deploy. If you complete a merge without deploying, your environment branch will be out of sync with your actual production environment.

With environment branches, you never want to commit changes directly to the branch. By only merging code from your stable branch into staging or production branches, you ensure that changes are flowing in one direction: from feature and bug-fix branches to stable and staging environments, and from stable to production. This keeps your history clean, and again, lets you be confident about knowing what code is running in which environments.

Best Practices with Environment Branches

Use your repository’s default working branch as your “stable” branch.
Create a branch for each environment, including staging and production.
Never merge into an environment branch unless you are ready to deploy to that environment.
Perform a diff between branches before merging—this can help prevent merging something that wasn’t intended, and can also help with writing release notes.
Merges should only flow in one direction: first from feature to staging for testing; then from feature to stable once tested; then from stable to production to ship.

TFS Standards Policy

16 August 2013 bryan Leave a comment

Rules to organise the process of Checking in and out of TFS is vital for preserving the integrity of our solution.

This list is by no means fool-proof and exhaustive and hence any suggestions are welcomed and encouraged.

Before Checking In or Out:
1. Consider getting latest.
2. Check if someone else has already checked the file out. If so, inform that person. This to avoid duplicating activities.
Checking out:
1. You can check out a file either explicitly by right clicking and select Check-out or implicitly by typing into the file.
2. Before Checking-Out, check that the file is already checked out by another person; if so, inform that user, this to avoid duplicating activities.
Checking In:
1. Before checking in make sure:
  1. The modified code compiles.
  2. The entire solution builds successfully.
  3. StyleCop rules implemented.
  4. Code reviewer is present.
2. Add clear and concise description to what has been changed and why.
3. Assign to Work Item(s) ID
4. Code reviewer name entered.
5. Never Auto-Merge; always merge manually.
6. Check that all new files, or relevant assembly in the global Library folder, have been successfully added to TFS. Missing such files might trigger Build Server failure.
After checking in keep an eye on the Build Server notification for successful build.
At the end of the working day; if the coding is not successfully completed, you must “Shelf” the files within TFS.
Make sure to regularly update relevant work items with progress and relevant comment.

TFS

The repository layout

25 April 2013 bryan Leave a comment

Team Foundation Server provides the ultimate flexibility in terms of how you arrange our data. Because it simply versions directories and files, and because it describes no particular meaning to any of those objects, you may arrange the data in your repository in any way that we choose. Unfortunately, this flexibility also means that it’s easy to find yourself “lost without a roadmap” as you attempt to navigate different Team Foundation Server project repositories that may carry completely different and unpredictable arrangements of the data within them.

To counteract this confusion, you can using a repository layout convention (established long ago) in which a handful of strategically named Team Foundation Server repository directories convey valuable meaning about the data they hold. Most projects have a recognizable “main line”, or trunk, of development; some branches, which are divergent copies of development lines. So we first recommend that each project have a recognizable project root in the repository, a directory under which all of the versioned information for that project—and only that project—lives. Secondly, I suggest that each project root contain a trunk subdirectory for the main development line, a branches subdirectory in which specific branches (or collections of branches) will be created.

In our case branches will contain the developers name followed by the TFS task item they are working on. This makes it very clear at any time who and what was required.

Trunk would be the main body of development, originating from the start of the project until the present.

Branches will be a copy of code derived from a certain point in the trunk that is used for applying major changes to the code while preserving the integrity of the code in the trunk. If the major changes work according to plan, they are usually merged back into the trunk.

Shelve Pending Changes stores your code changes on the server but doesn’t commit them to the branch. Here are some reasons for using it:

To save changes but undo locally when I’m not ready to commit changes but I need to make an emergency bug fix on the same branch.
To store code for code reviews prior to committing. Other people can check out or view your shelved changes.
To store changes that are ready for committing when the changes aren’t approved yet.

One thing to know about shelving changes: When you unshelve, you get the file as-is. If someone else has modified the file after your shelve, no merge happens. So I don’t recommend shelving changes long-term.

Here are some examples of the structure

$abc[1]\src\csp\trunk

$abc\src\csp\branches\David Jason\3243

$abc\src\csp\branches\David Jason\3122

The repository main root has the following structure and shortened names, this is because Visual Studio has a 260 character name length restriction.

src Source Code

dep Deployments

If you are making a large Branch it is recommended that you plan you merge back to your trunk when you branch, as the longer period of time the Branch is separated from the Trunk the more work is going to be required to merge the two back together. As a rule of thumb one week is acceptable where as one month is much too long and will result in a lot of merge conflicts. If the branch is out of the main trunk for more than a month then before the code is merged back to the main trunk full testing of the source will be required, both unit tests and system integration testing which will require to be signed off by the test team that it passes full regression testing before the code is merged back to the main trunk.

With larger branches they can have their own trunk and branches while they are being worked on. If a sub trunk has been created then it is best practice to make sure a build is triggered on all checkins to this trunk to ensure that the code can be build successfully on the build server. It is important that the above paragraph on merging back is adhered to.

[1] This is the your project level for the Repository; you will find many others as these are historic and should only be used for reference.

SQL, TFS, Visual Studio 2012

Deploy a database project with TFS Build

27 February 2013 bryan Leave a comment

When you develop web application you often have this scenario. Some people are testers, they are testing the application in dev all day, and they want always to test latest version. Moreover testers usually fills data into web application, so they want their data to be preserved between various deploy. If you simply clear all data in test database you will end with a lot of furious tester so do not even think to do this.

If a developer needs to change database schema, we need to automate not only the deploy of the web application, but we need also to sync test database with the latest changes. This is necessary so the test site can work with the new version, but old data is preserved for the happiness of the testers.

This is quite simple using TFS and Database project. The situation is this one

When a developer does a check-in, the build server grabs the tip from TFS, then it runs the builds script and deploy the new version of the site in the test web server. At the same time test database gets updated with the latest database schema.

Next we need the ability to automatically deploy changes to a specific database, this task is quite simple and you can find some details here in msdn, but we need to insert this command into the msbuild script. Here is the code:

<Target Name="AfterDropBuild"><Message Text="Deploy of project database" />
<MSBuild Projects="$(SolutionRoot)srcDbEditionNorthwindTestNorthwindTestNorthwindTest.dbproj"
Properties="OutDir=$(DropLocation)$(BuildNumber)debug;
TargetDatabase=NorthwindCiTest;
DefaultDataPath=C:Program FilesMicrosoft SQL ServerMSSQL.4MSSQLData;
TargetConnectionString=Data Source=VM2003R2_1SQLTEST%3Buser=sa%3Bpwd=Pa$$w0rd;
DeployToDatabase=true;" 
Targets="Deploy"/> 
</Target>

Original post from Ricci Gian Maria

http://geekswithblogs.net/jakob/archive/2012/04/25/deploying-ssdt-projects-with-tfs-build/

Bryan Avery – Blog