New Release Definition Editor–Team Services

Release definition in Team Services helps you to define deployment pipelines across target environments. You can setup a release definition to deploy via agents, deployment groups or execute agent less activities. With the latest update to Team Services a new release definition editor is introduced. Let’s ex[lore the new editor.

Sizing Backlog Items with Team Services

Backlog item sizing will help an Agile team to identify their velocity and plan for future iterations/sprints considering it. It is important the team members have discussed a backlog item and have a common understanding on what needs to be done before it is relatively estimated. Sizing for backlog items in Team Services work items such as User Story, Bug can be updated in Story Points or Effort field depending on the template you are using. Team Services extension, “Estimate” is available in Visual Studio Marketplace allow you to do effective estimating of backlog item, by enabling team to vote for each work item using on Team Services, while getting Story Points or Effort field update automatically with the size value, once team is committed to a size.

Ignoring Visual Studio 2017 Created Files in Git

Visual Studio 2017 creates few files such as slnx.sqlite, .suo and these files often give trouble if you get it added to a branch in Git version control. Every time you open a solution in Visual Studio 2017, these files are indicated as pending changes and you are unable to do a pull, push etc. without undoing or committing these files. This is annoying since you actually do not want these to be added as changes to version control repository. You can try completely removing the files not needed from repository but if you are not willing to go through somewhat risky procedure, what options you have for solving this problem?

Let’s look at how to fix this issue.

.gitignore

Adding unwanted files to .gitignore works as long as you have not initially committed them to any branch. But in this case where it is already committed adding .gitignore entry such as /.vs/slnx.sqlite does not help.

Ignore changes to the files

You can run below command to ignore the changes to these files by assuming they are unchanged.

git update-index --assume-unchanged filename

To run the command open command prompt from team explorer window of Visual Studio by right clicking on the repository name of the connect page.

The command git update-index --assume-unchanged slnx.sqlite gives error “fatal: Unable to mark file slnx.sqlite” because it actually cannot find the file.

To find the correct paths you can execute git ls-files command and use the path listed to mark the file. You can list git untracked files as well by executing git ls-files -o but untracked files cannot be marked. Adding them to gitignore would be sufficient.

Providing correct path to file from the location you are running the command will make it execute without error message.

slnx.sqlite file no longer considered as changed.

You can undo the the assume-uchanged state by executing command below.

git update-index –-no-assume-unchanged filename

Team Services - Custom In Progress Sate to Completed State – Closed Date Not Updating Issue

Update! – Issue described here is now resolved in Team Services and it has even included fix for last column order issue as well.

Team Services now allows work item states to be customized and you can change the workflow to your preference. This is explained in the previous post “Custom States for Work Items in Team Services with New Process Customization Experience” in detail. As explained there you can hide available default states and use your custom sates instead of them. But as of now state change from a custom state to Completed category state does not update the Closed Date and Closed By fields in Bug and User Story/PBI work items. For Task work item in custom state , changing to Completed category state, updates Closed Date but not the Closed By field.

Let’s further understand this issue with an example.

Custom States for Work Items in Team Services with New Process Customization Experience

Custom states for work items could be introduced and usage of new custom workflow for state transitions, is possible in team services from some time back. The post here describes how to customize work item states. With latest updates to Team Services a new process customization experience is introduced as described in “Team Services Process Customization”. Let’s  explore the state workflow customization of work items with the new process customization experience.

Team Services Process Customization

Team Services is coming up with many improvements and one of it is the new process customization experience introduced recently. This allows you to have your own custom work item types, custom work item state flows and custom fields for work items etc. It is made easier to start customizing even directly from work item form. Let’s look at and understand process customization options available for you to optimize your work process.

Deploying Web Apps to Azure Virtual Directories

My friend Jaliya Udagedara has written nice post here, explaining how to deploy a Core web application into Azure App Service Application virtual directory. Below is comparison of few more settings you can use with Azure virtual directories.

Deployment Groups in VS Team Services

Deployment groups provide robust out-of-the-box multi-machine deployment with team services release management. It allows you to run deployments across multiple machines. You can install agent on each of your target servers directly and run rolling deployment to those servers, unlike agent based deployments where you install build/deployment agents on proxy servers in an agent pool. You can use all tasks in task catalog on your target machines.

Deployment group allows you to create target deployment machine groups, without requiring you to register machines in agent pools or queues. Machine in a deployment group will have an agent registered with the named deployment group, within the team project providing required isolation for target environment (such as DevInt, QA, UAT, Demo, Production etc.), for a given product or project.

Logical group of targets (machines) having an agent installed on each of them is a deployment group. It represents your physical environments. It can be single-box, multi-machine or a farm of machines. You can specify the security context for your physical environments by using the deployment groups.

Let’s look at how to create a Deployment Group in Team Services.