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.