Restrict State Transitions in Azure DevOps Work Items

 Azure DevOps work items for example User Story work item can be moved from one state to another in a workflow. As per this question in tech communties a requirement is there to resrict a New state user story from moving to Closed state directly. But if the uer story is in another state such as Active it should be able to moved to Closed state. Let's explore how to implement a solution for this Azure DevOps.

We can use customized templates in Azure DevOps to customize the work items and work flows. To restrict moving a user story from New to Closed state we can implement a rule in user story work item as below.

• Open custom template user story work item.
• Then go to rules tab and add a new rule.
• Provide a rule name. 
• Add condition "Work item state is moved from" and select New as the value.
• Add action "Restrict transition to state" and select Closed as the value.

Customizing Columns in Your Azure DevOps Sprint/Task Boards

Kanban flow of the Azure Boards for user stories, features or other top level back log boards was a feature available in Azure DevOps Boards for a long time. However, it was not possible to change the sprint board columns in Azure DevOps, without introducing new states to Task work item or any work item which is using sprint board previously. This long awaited community request has been now completed and available in Azure DevOps services. Azure DevOps on-premise server does not have this feature we can hope it would be added to the on-premise server eventually. Let’s look at how we can customize the columns in the Sprint boards with this new feature.

Business Rules for Work Items in Team Services

For inherited process model in VSTS, you can use Custom Rules to define rules that can clear the value of a field, copy a value into a field, and apply values based on dependencies between different fields' etc. You can define actions against conditions using custom rules. This provide you the flexibility in VSTS to go beyond the level of setting a default value or making a field required. To customize work items in an existing team project of Hosted XML model for VSTS, or on-premises TFS, you have to customize, downloaded process template or individual work item XML files (using witadmin tool) respectively. Differences between process models are described here.

Changing Work Item Icons – TFS vs VSTS

It is now possible to change the work item icons  in on premises TFS  2017.2 and in VSTS. This is a cool feature allowing you to, recognize the type of work item at a glance. However there is a significant difference  between TFS and VSTS how you apply this change. Let’s explore how we can change icon for existing and any new tem projects in both TFS 2017.2 (works just same in TFS 2018 RC1) and in VSTS.

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.

Show/Hide Work Item Field Based on Value in Another Field

Is it possible? To show/hide work item field based on value in another field. Answer is yes and no. Let me show you why and how.
Let’s create a condition field with two options

Next we’ll create a second field which is using WHEN condition with READONLY is the vale in condition field is NotEditable.

Add the two fields to Form like below and we’ll see how it works

When the second field is having no value (empty) then it is hidden when selected “NotEditable” in condition field and shows when it is selected “Editable” in condition field.

When you have a value in the second field it is set to readonly and editable mode instead of hide and show.

If you want to handle multiple values in condition field, and some of them set the second field show-hide/readonly-editable you can do it as shown below.

Experiment on Limit AssignedTo field of WIT to Team Members

A question in MSDN Forum lead me to do some experiments on restricting AssignedTo field of a work item to Team Members.

Here are some notes

1. I created team project CustomizeTest
2. This created default team "CustomizeTest"
3. I tried modifying Bug WIT template AssignedTo field

<ALLOWEDVALUES expanditems="true" filteritems="excludegroups">
    <LISTITEM value="[project]\CustomizeTest" />
  </ALLOWEDVALUES>

TFS template was not imported. Error
Error importing work item type definition:
TF26204: The account you entered is not recognized. Contact your Team Foundation Server administrator to add your account.
4. Created a new team "Team1" and tried with

<ALLOWEDVALUES expanditems="true" filteritems="excludegroups">
    <LISTITEM value="[project]\Team1" />
  </ALLOWEDVALUES>

Wow it works fine.
5. So where did I go wrong.... Got it... The default team of team project "CustomizeTest" is created as "CustomizeTest Team"

<ALLOWEDVALUES expanditems="true" filteritems="excludegroups">
    <LISTITEM value="[project]\CustomizeTest Team" />
  </ALLOWEDVALUES>

Works fine.
OK That is that and it works...BUT

Another experiment notes

1. I assigned one member to my Team1
2. Customized Bug WIT AssignedTo field to have

<ALLOWEDVALUES expanditems="true" filteritems="excludegroups">
    <LISTITEM value="[project]\Team1" />
  </ALLOWEDVALUES>

3. Went into Team project CustomizeTest\Team1 and tried creating Bug. Assigned To field drop down have only one member. yeah I am happy.
4. Went into root team project CutomizeTest (CustomizeTest Team) Create Bug. AssignedTo field only has that one member in Team1. Ok it should be since I have made it to work like that.  (my CutomizeTest Team has 3 Members but I can assign a bug in this team only to one member of the Team1, looks like I made some bad customization)
5. I created another Team "Team2" with 2 members.  and modified my Bug WIT AssignedTo field to have

<ALLOWEDVALUES expanditems="true" filteritems="excludegroups">
    <LISTITEM value="[project]\Team2" />
  </ALLOWEDVALUES>

Now when I go into "CustomizeTest Team", "Team1" and "Team2". Create a bug I can assign it to only to the two members of the "Team2".
6. I changed my Bug WIT AssignedTo field to

<ALLOWEDVALUES expanditems="true" filteritems="excludegroups">
    <LISTITEM value="[project]\Contributors" />
  </ALLOWEDVALUES>

and I added teams "CustomizeTest Team", "Team1" and "Team2" as members of [project]\Contributors.
This lists all members from the three teams in my AssignedTo field regardless of the team I am in.
Think all above my experiments will help someone in some way.

If there is  a way to say <LISTITEM value="[project]\<TheCurrentTeam>" /> which would be wonderful to have I think.

TFS - Lab Build - Deployment Script - Copy Build Output Zip to Lab Env. Machine and Extract

As a continuation to my last post "TFS - Lab Build - Create Zip File with Build Output in the Drop Folder", today I am going to explain how to use a deployment script with lab build (Build-Deply-Test workflow), to copy the build out put zip file, to Lab Environment Machine and extract.

1. First I am going to create a batch file and a PS script. My PS script will do all the work. Batch file (.bat) will be used to initiate the powershell script from Lab Workflow. To get this to work I need to make sure my batch file and the PS script is copied to build output folder, since it is the place that I can execute a deployment script from Lab Work Flow.

I have added my .bat file and the PS script file under a VS project that is under a solution I am building, and set the Copy to Output as always.

2. This will copy my .bat and PS script to Build Drop folder.

3. This is what I have in my .bat file. It is simply executing the PS script making sure execution policy is not blocking anything. Build location here is passed as an argument from the Lab Workflow.

4. In my Lab Build in the deployment steps I specify the .bat file to run as below. For more information and how to use xcopy to copy build out put have a look at "Creating Deployment Scripts for Build-Deploy-Test Workflows". I used a poweshell script since I am going to do lot more than just copying files, like adding dlls to GAC, etc which I will explain in a next post.

$BuildLocation is giving the build output location of the build that is queued/used by  Lab workflow.

5. In my poweshell script I am copying zip to my lab environment machine. The path C:\ ..refers to the path in the lab environment machine, since  the deployment script get executed in the context of given lab environment machine as specified in the above screenshot.

After copying this script will extract contents to the copied location and remove the zip file from the Build Drop folder. Build Location is passed to the poweshell script from the above .bat file as a parameter.

6. I queue a build and I can see my zip file copying actions get executed in the Build Log as below.

7. In my lab environment machine I see the extracted files .

 

This is cool .. don't you think..

TFS - Lab Build - Create Zip File with Build Output in the Drop Folder

Sometimes it takes long time to copy files from drop folder to the lab environment when you have your lab environment in different locations( distributed environments), and you have several hundred files in your drop folder (example - published website with lot of files).

I will explain how to use a Build Activity to zip, by customizing LabDefaultTemplate.11.xaml.

How to add a custom code activity to a build template is clearly explained in this article http://www.ewaldhofman.nl/post/2010/04/29/Customize-Team-Build-2010-e28093-Part-4-Create-your-own-activity.aspx

Go through the above article if you want to know the basics.

So lets look at how to add a build activity to zip the build output.

1. First you need to have a code activity similar to below

2. Once compiled and add reference to your build template project you can view the New Activity --> Zip in the Toolbox when you open the build template.

 

3. Drag and drop the  Zip activity to LabDefaultTemplate.11.xaml after the "Compute build location needed" activity to make sure BuildLocation variable is filled with the correct build location (This variable will contain the Build Folder path of the Build queued or used by the Build task of the Lab Workflow).

4. Set the properties as below in the Zip build activity. DirectoryLocation is set to Build Location and Zip file path will be Build Location path with ".zip" extension. This will make sure zip file is created at the drop location of the build used by the lab workflow.

5. Create a build definition using the lab template and set the lab workflow build step to use the release build definition of yours (Output of this build will be used to create the zip file).

 

6. Queue a build with the lab build and you will see lab(build-deploy-test) build, queues  the release build, once complete use the build location and create the build output as a zip file.

7. In the drop location of the release build you will have the build out put files and the zip file of the output.

In my next post, I will explain "How to use a deployment task of the Lab Workflow to copy the output zip file and extract it in the Lab Environment Machine".