Get Pod Counts via Kubectl in WSL

 It would be usefull to figure out how many pods running in a given AKS cluster sometimes for various diagnostic needs. In this post let's see how we can use kubectl command to get pod count in diffrent combinations.

Below are some examples.

Using Remote Terraform State

 Sometimes resources common to multiple diffrent setups might need to be created with a common terraform code. In such cases the commeo terraform resources may need to be reffered with its state in  other terraform code. For this requirement we can use terraform remote state. Let's see how we can use terraform remote state step by step in this post.

The expectation is to refer to the Azure resources in remote terraform state as shown below. Here you can see we have reffered to the resource group name and location, and to log analytics workspace id from remote state.

Performing Terraform Import via Azure Pipelines for Existing Azure Resources

Importing state to terraform may be required when a resource is manually created previously, now need to be managed by terraform. Or it can be a situation where you Move code from one repo to another for reorganizing purpose and now you need to refer to exesting resource in Azure and map it to new repo terraform code. The state import can be performed with terraform import command manually. However, performin such task manually targeting production environments is not ideal and kind of impossible, in autmated deployment implementations. In this post let's discuss, a Azure pipeline task that can be used to perform the state imports in a rerunnable way.

Such task toupdate terraform state in Azure pipline should be placed between the terraform init and terraform plan tasks as shown below.

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.

Set Work Item State on Pull Request Completion

Associated work items help to identify what is completed in a given pull request. If required while completing a pull request you could, set the associated work item to be moved to completed state. With the introduction of new feature, which we are discussing in this post, you would be able to set the work item state (regardless of it is associated work item or not for the pull request) to desired closed, in progress or resolved states based on description specification.

Why Azure DevOps Terraform Extension Task by Microsoft DevLabs to Deploy Infra to Azure Does Not Work for Me

Terraform is used as declarative code for infrastructure deployments on multiple cloud platforms including Azure. Azure DevOps provides capability to execute Infrastructure as code (IaC), with CI/CD pipelines, by using tasks added with the extension by Microsoft DevLabs (https://marketplace.visualstudio.com/items?itemName=ms-devlabs.custom-terraform-tasks) available in the marketplace. The terraform task to plan or apply a terraform plan demands to have reources in Azure such as a resource group, storage account, container and a key (terraform state file path). Similar demands are there for even AWS and GCP for when using the task.

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.

MSF Agile - Bug WIT - Adding to Backlog with State New

We do not get Bug work item in Backlog for MSF Agile process template. But it is a good idea to have it on the backlog, since the team then will know there are more work to be done. With VS Scrum template we have this as default option.

If we only add the Bug work item to the Backlog, again it becomes a bit of a issue. Why? Because in MSF agile template the initial State of Bug work item is Active. So there will be lot of Active bugs in the board and unassigned..looks bad..isn't it?

What if we introduce a new State to Bug, as "New", and make the Bug to have New, Active, Resolve, Close (4 States) rather than having Active, Resolve, Close (3 States).

OK, lets do it step by step for a team project and see how it goes.

1. First we have to have TFS power tools for VS 2012 update 2 installed to get the customizations done. http://visualstudiogallery.msdn.microsoft.com/b1ef7eb2-e084-4cb8-9bc7-06c3bad9148f

2. Export Bug Work item as below.

 

2. Open Bug work item template.

3. Choose file saved in step 1

4. In power tools process template editor you can do the modification to add new state for the Bug work item workflow easily using the GUI.

a) Bug work item state transition  - MSF Agile default

 

b) Add new State "New"

c) Easy to modify in GUI

d) But easier to open the Bug.xml file in notepad and edit as per below.

•      Add new State "New"

• Remove "" to Active Transition and add the Transitions as below

e) When above changes done, save it as BugModified.xml. Open it in Process template editor, and you should see the new state transition workflow like this.

 f) Now import the  BugModified.xml to the team project using power tools. (Process Editor --> Work Item Types -- > Import WIT)

h) Make sure to add verify fields "Story Points" (Size of Bug - Similar to User Story Size) and "Stack Rank" (to prioritize the backlog items) available in the bug WIT. If not available add them.

 5. Now the Bug work item has new State "New"

6. Now we have to do some modifications to categories, and common config to get the Bug into backlog and to meke sure drag and drops work in Board.

7. Open command prompt in TFS server and  change directory (to use witadmin) using

cd C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE

8. Execute below command with correct collection and team project name

witadmin exportcategories /collection:http://localhost:8080/tfs/defaultcollection /p:Demo.MSFAgileModified /f:"C:\temp\Categories.xml"

9. Open Categories.xml notepad and add the text in green box in the Requirement Category and save the as CategoriesModified.xml

 10. Execute below command to get CommonProcessConfig.xml

witadmin exportcommonprocessconfig /collection:http://localhost:8080/tfs/defaultcollection /p:Demo.MSFAgileModified /f:"C:\temp\CommonProcessConfig.xml"

Change as below (add green box text to bug category) and save the file as CommonProcessConfigModified.xml
 









11. Now import the two modified xmls using below two commands


witadmin importcategories /collection:http://localhost:8080/tfs/defaultcollection /p:Demo.MSFAgileModified /f:"C:\temp\CategoriesModified.xml"

witadmin importcommonprocessconfig /collection:http://localhost:8080/tfs/defaultcollection /p:Demo.MSFAgileModified /f:"C:\temp\CommonProcessConfigModified.xml"

12. Check the backlog and all now the bugs appear in the backlog

13. When click on board .. err.. :(

14. Before our imports Column Options in the Board looked like

 15. But now

 16. The fix

 17. Great.. the Board is back in operation

18. State transition with drag drop works fine...

If this was done on TFS 2013 preview... Bug would have a different color theme as well..