Category Archives: Planning

Use oData to pull data from ADO

Data Source

Epic

let
Source = OData.Feed(“http:// <adoServer>/<adoCollection>/<adoProject>/_odata/v1.0” & “/WorkItems?$filter=WorkItemType eq ‘” & “Product Backlog Item” & “‘ and state ne ‘Removed’ and CreatedDate ge 2020-01-01T00:00:00-06:00″, null, [Implementation=”2.0”]),
#”Removed Other Columns” = Table.SelectColumns(Source,{“WorkItemId”, “PlanningType”, “ReportCategory”, “RequestedStartDate”, “RequestedDueDate”, “Date_Done”, “EstimatedHours”, “WorkedHours”, “LeadTimeDays”, “CycleTimeDays”, “ProjectSK”, “WorkItemRevisionSK”, “AreaSK”, “IterationSK”, “AssignedToUserSK”, “CreatedByUserSK”, “Revision”, “Watermark”, “Title”, “ParentWorkItemId”, “WorkItemType”, “ChangedDate”, “CreatedDate”, “State”, “Effort”, “TagNames”, “StateCategory”, “BoardLocations”, “Teams”, “Parent”, “Iteration”, “AssignedTo”, “Tags”})
in
#”Removed Other Columns”

Feature

let
Source = OData.Feed(“http:// <adoServer>/<adoCollection>/<adoProject>/_odata/v1.0” & “/WorkItems?$filter=WorkItemType eq ‘” & “Feature” & “‘ and state ne ‘Removed’ and CreatedDate ge 2020-01-01T00:00:00-06:00″, null, [Implementation=”2.0”]),
#”Removed Other Columns” = Table.SelectColumns(Source,{“WorkItemId”, “LeadTimeDays”, “CycleTimeDays”, “ProjectSK”, “WorkItemRevisionSK”, “AreaSK”, “IterationSK”, “AssignedToUserSK”, “CreatedByUserSK”, “Revision”, “Watermark”, “Title”, “ParentWorkItemId”, “WorkItemType”, “ChangedDate”, “CreatedDate”, “State”, “Effort”, “TagNames”, “StateCategory”, “BoardLocations”, “Teams”, “Parent”, “Iteration”, “AssignedTo”, “Tags”})
in
#”Removed Other Columns”

PBI

let
Source = OData.Feed(“http://<adoServer>/<adoCollection>/<adoProject>/_odata/v1.0&#8221; & “/WorkItems?$filter=WorkItemType eq ‘” & “Product Backlog Item” & “‘ and state ne ‘Removed’ and CreatedDate ge 2020-01-01T00:00:00-06:00″, null, [Implementation=”2.0”]),
#”Removed Other Columns” = Table.SelectColumns(Source,{“WorkItemId”, “PlanningType”, “ReportCategory”, “RequestedStartDate”, “RequestedDueDate”, “Date_Done”, “EstimatedHours”, “WorkedHours”, “LeadTimeDays”, “CycleTimeDays”, “ProjectSK”, “WorkItemRevisionSK”, “AreaSK”, “IterationSK”, “AssignedToUserSK”, “CreatedByUserSK”, “Revision”, “Watermark”, “Title”, “ParentWorkItemId”, “WorkItemType”, “ChangedDate”, “CreatedDate”, “State”, “Effort”, “TagNames”, “StateCategory”, “BoardLocations”, “Teams”, “Parent”, “Iteration”, “AssignedTo”, “Tags”})
in
#”Removed Other Columns”

Area

let
Source = OData.Feed(“http:// <adoServer>/<adoCollection>/<adoProject> /_odata/v1.0”),
Areas_table = Source{[Name=”Areas”,Signature=”table”]}[Data],
#”Removed Columns” = Table.RemoveColumns(Areas_table,{“ProjectSK”, “AreaId”, “Number”, “AreaLevel7”, “AreaLevel8”, “AreaLevel9”, “AreaLevel10”, “AreaLevel11”, “AreaLevel12”, “AreaLevel13”, “AreaLevel14”, “Depth”, “Project”, “Teams”})
in
#”Removed Columns”

User

let
Source = OData.Feed(“http://<adoServer>/<adoCollection>/<adoProject>/_odata/v1.0&#8221; & “/Users”),
#”Removed Other Columns” = Table.SelectColumns(Source,{“UserName”, “UserSK”})
in
#”Removed Other Columns”

Iteration

let
Source = OData.Feed(“http://<adoServer>/<adoCollection>/<adoProject&gt; /_odata/v1.0”),
Areas_table = Source{[Name=”Iterations”,Signature=”table”]}[Data],
#”Removed Columns” = Table.RemoveColumns(Areas_table,{“ProjectSK”, “IterationId”, “IterationName”, “Number”, “IterationLevel7”, “IterationLevel8”, “IterationLevel9”, “IterationLevel10”, “IterationLevel11”, “IterationLevel12”, “IterationLevel13”, “IterationLevel14”, “Depth”, “Project”, “Teams”})
in
#”Removed Columns”

Custom Fields/Columns

PBI

AssignedTo

AssignedTo = LOOKUPVALUE(oData_Users[UserName], oData_Users[UserSK], oData_PBI[AssignedToUserSK])

CreatedMonth

CreatedMonth = FORMAT(MONTH(oData_PBI[CreatedDate]), “00”) & “-” & FORMAT( oData_PBI[CreatedDate], “mmmm”)

CreatedWeek

CreatedWeek = “WK” & FORMAT( WEEKNUM(oData_PBI[CreatedDate]), “00”)

IterationPath

IterationPath = LOOKUPVALUE(oData_Iterations[IterationPath], oData_Iterations[IterationSK], oData_PBI[IterationSK])

MyRequestedDueDate

myRequestedDueDate = IF ( IF (oData_PBI[RequestedDueDate] = BLANK(), oData_PBI[Date_Done], oData_PBI[RequestedDueDate]) = BLANK(), TODAY() + 7 – WEEKDAY(TODAY(),2), IF (oData_PBI[RequestedDueDate] = BLANK(), oData_PBI[Date_Done], oData_PBI[RequestedDueDate]))

MyRequestedStartDate

myRequestedStartDate = IF (oData_PBI[RequestedStartDate] = BLANK(), oData_PBI[CreatedDate], oData_PBI[RequestedStartDate])

WorkitemCountRunningTotal

WorkitemCountRunningTotal = CALCULATE(DISTINCTCOUNT(oData_PBI[Title]), FILTER( ALL( oData_PBI ), oData_PBI[CreatedDate] <= EARLIER( oData_PBI[CreatedDate])))

Feature

PBICompletedCount

PBICompletedCount = VAR num = CALCULATE( COUNTROWS(RELATEDTABLE(oData_PBI)), FILTER( RELATEDTABLE(oData_PBI), oData_PBI[StateCategory] = “Completed” ) )RETURN IF(ISBLANK(num), 0, num)

PBIPercentOfCompletion

PBIPercentOfCompletion = var perc = [PBICompletedCount]/[PBITotalCount]RETURN IF([PBITotalCount] = 0, 0, IFERROR(perc, 0))

PBITotalCount

PBITotalCount = VAR num = CALCULATE( COUNTROWS(RELATEDTABLE(oData_PBI)))RETURN IF(ISBLANK(num), 0, num)

Change Azure DevOps Server (TFS) Service Account Passwords

Sometimes, you will have to change all service account’s passwords at once either they are expiring or security compliance requiring you to do that. Although we can get on the server and change the service accounts, due to multiple components Azure DevOps Server (formally known as TFS) has, it was quite a trouble to do so.

Components:

  • App Tier
  • Build & Deployment groups agents
  • SSRS

Interfaces:

  • Admin console
  • Windows services
  • Pipeline (Build & Release) definitions

Environments

  • DEV
  • QA
  • Prod

Solution

  • Setup a pipeline to streamline the processes
    • PS to change passwords
    • PS to change SSRS data source
    • App tier
      • tfsconfig Accounts /UpdatePassword /account::$serviceAccountName /Password:$(ServiceAccountPassword-New) /continue
    • PS to change all agents
  • Scripts
  • ChangeServiceAccountPasswords

Use AD groups for TFS 2015

AccessLevels

If you are interested to know the broader view of how TFS manage users and groups, you can refer to this post. To recap, here are some pros and cons.

PROs:

  • Take the burden of “approving” user access – Unless it’s for a pretty small company, TFS administrators are not actually approving anybody’s access anyway. They are just doing the actual work. Even worse is that if the access request starts at TFS team, there will be more emails/IMs going back and forward between TFS team and Dev managers before an user’s access is granted. There is yes and no desision and how, where, and what to the access level. The decision makers should be in Dev team’s hand. We just need to make sure all parties fully understand the scope and meaning of those access.
  • Should users left the company, we can just take care the accounts from AD (by Network/Security teams) and not worry too much about maintaining the integrity of user lists especially now TFS has multiple components like Code, Work, Build, and Test to manage. Needless to say those integration outside of TFS like SharePoint and SSRS.

CONs:

  • It is not Agile any more. Now the whole “processes” are more corporate/audit oriented. Team leaders can not easily to utilize boards as planning and communication tools before. I think it is a trade-off, depends on where your organization at in the lifecycle of organizations.
  • More managing overhead. This is kind of contradict to the point above. We tried to eliminate the headache from TFS administrators by adding more layers and groups to the equation. Eventually the AD groups will grow into something that even those Dev teams not sure which group is the right group to put people and what the impact is for different combination of the groups.

Just in case you are still interested in using AD groups alone to manage TFS users. Here are some AD groups you will need.

  • TFS-<Collection>-CollectionAdministartors
  • TFS-<Collection>-CollectionBuildAdministrators
  • TFS-<Collection>-CollectionBuildServiceAccounts
  • TFS-<Collection>-<Project>-ProjectAdministrators
  • TFS-<Collection>-<Project>-ProjectBuildAdministrators
  • TFS-<Collection>-<Project>-<Queue>-QueueAdministrators
  • TFS-<Collection>-<Project>-<Queue>-QueueUsers
  • TFS-<Collection>-<Project>-<Team>-Code-Administrators
  • TFS-<Collection>-<Project>-<Team>-Code-Developers
  • TFS-<Collection>-<Project>-<Team>-Code-Contractors
  • TFS-<Collection>-<Project>-<Team>-Code-Readers
  • TFS-<Collection>-<Project>-<Team>-Board-Administrators
  • TFS-<Collection>-<Project>-<Team>-Board-Members
  • TFS-<Collection>-<Project>-<Team>-Release-PreDeployApprovers
  • TFS-<Collection>-<Project>-<Team>-Release-PostDeployApprovers
  • TFS-<Collection>-<Project>-<Team>-Release-EnvironmentOwners
  • TFS-<Collection>-<Project>-<Team>-Test-Testers

Proposed AD groups for TFS Users

TFS User Management

How TFS manages its users and groups and how we manage it.

Quick Notes:

  • TFS was originally designed as a source control system for developers only
  • Evolving over time (Acquisition & Integration)
  • Multiple management mechanism
  • Emphasize on ease of use and flexibility
  • Least-Permissive Model

TFS-Env-1TFS-Env-2OutsideTFSPermTypes-1PermTypes-2PermTypes-3PermTypes-4PermTypes-5PermTypes-6

There is a discussion about moving every individual into AD groups. Here are some thinking:

  • Pros
    • TFS Admin should not “approve” user classification
    • Functional or organizational leaders should
    • Save a round of communication
  • Cons
    • Lose flexibility
    • Not Agile/Scrum any more
    • Hard to have clearly pre-defined AD groups (or have too many AD groups to manage)
    • Board only
      • Ready Only
      • View and Edit
    • Board and Code
      • Ready Only
      • Edit (Check in)
      • Branch
      • Merge
      • Manage permission
      • Manage others’ changes
    • Specific Code Only

 

TFS 2017 Upgrade

Microsoft-Team-Foundation-Server-2017-MSDN-Direct-Download-ISOsResearch

Analyze

Plan

POC

  • Server Setup

    • Request New Servers
      • Data tier – SQL 2016
      • App tier – Win 2012
      • Build – Win 2012
      • SSRS – SQL 2016
      • Data Warehouse – SQL 2016
      • SSAS – SQL 2016
      • SharePoint – Win 2012
      • Integration – 2012
    • Request New Service Accounts
      • svc-tfssetup
      • svc-tfsservice
      • svc-tfsbuild
      • svc-tfsreport
      • svc-tfssp
    • Download Software
      • TFS 2017
      • VS 2017
      • SQL 2016
      • TFS 2017 Powertool
      • SharePoint 2013
    • Request Account Privileges
      • Local Admin group
      • SQL sysadmin & serveradmin roles
    • Install & Config
    1. Data tier
    2. App Tier
    3. Build Agents/Pools/Queues
    4. Test Agents
    5. SSRS
    6. Data Warehouse
    7. SSAS
    8. SharePoint
    9. Integration (Optional)
  • Data Migration

    • TFS
    1. Backup from TFS 2015
    2. Restore to TFS 2017
    3. Grant permission to newly created service accounts
    4. Upgrade database from 2015 to 2017
    • SSRS
    1. Back from old server
    2. Restore to new server
    • SharePoint
    1. Back from old server
    2. Restore to new server
  • Validation

    • Code
    • Work Items
    • Build & Release
    • Test
    • Queries
    • Dashboard
    • Reports
    • SharePoint
  • Documentation

    • Notification for
      • Upgrade Schedules
      • Changes Items
      • Contact bridges, email addresses, extensions
    • User Guides for
      • Upgrade Personnel
      • End Users

Upgrade

  • Research period
  • Analyze period
  • Plan period
  • POC period
  • Validation period
  • Upgrade Date & Time
    • Pre-upgrade notification
    • Cutoff – kick everybody out & stop services
    • Backup – Databases & VMs
    • Restore
    • Config
    • Validate
    • DNS change
    • Final Go/No-Go checkup
    • Post-upgrade notification
    • Soaking period to retire old servers

A Journey of Implementing TFS 2015

These were teams with basic Agile (Scrum & Kanban) training and been using TFS only as source code repository in the past. Developers had been specialized in each of their own applications and were about to start pooling together to form a more collaborate force. So no branching (and merging), no work items, no work item association at check-in, and of course no standard build and deploy processes and environments yet. What a exciting journey this will be!

“The main thing is to keep the main thing the main thing”      ~ Stephen Covey

I want to keep the interest of early adopters by keeping the system stable and up-to-date. In the meantime, seeing is beleiving. It helps to have environments for me to demo and POC some ideas for my potential users. Then it will come down to prioritize what goes first with limited resources and time. Few important things for me and the teams are

  • A healthy and up-to-date TFS environment
  • Provide custom solutions which also aleign with industry trends and new technology
  • Evangelize and POC for potential proposal

However, business priority overrules technology came to the equation when trying to prioritize the implementation tasks. Furthermore, those priorities changed dynamically as well. This challenge is pretty common in many companies for IT department. The only difference in my case is that now the IT teams are the end users for me while I am also part of IT too.

So we did the upgrade from TFS 2013 to TFS 2015 after applying few updates for TFS 2013. The goal is to keep the system current. Interestingly, the side benefit of the multiple smooth upgrades also helped me gain some trust gradually. There were some big database schema changes between 2015 and 2013 followed by additional changes in TFS 2015 Update 1 & 2. Application layer wise, Release Management is fully integrated into TWA (TFS Web Access) now, TFS extension market place is available, and more supported custom widgets are possible starting in Update 3 now.

To gain more buy-in, I explorerd and eventually customize two version of Work Item card printing solution for some teams using physical boards on the walls with sticky notes. The organizational culture is not too exciting about new technology and changes. So for those teams finally took the leap of faith by jumping on new Agile practice and set up boards on the wall few months ago, printing out cards is a most acceptable step because “moving cards” was what they were trained for Agile. I did get sidetracked on some customization and support for this printing effort. But during the processes, I also got to know more teams’ unique requirements and the chance to show-and-tell some TFS features.

As more and more data moved into TFS from various traditional tracking means i.e., sticky notes, Excel spreadsheets, SharePoint lists, etc. along with improved and more friendly TWA, department head finally agreed to go electronic and move all boards to TFS if we can solve some of his concerns and requirements.

  • Can TFS report departmental work loads, trends, unexpected activitiesetc. to help explaining the delivery to business users
  • Each team has their own unique flows of running the boards. Would it be too much customization for future maintenance. Some of the teams suffered from painful upgrades caused by customization in the past and very sensitive about it.
  • Can TFS boards be flexible enough to fit different teams special needs?
  • Can his teams do this without affecting other more established teams?

Fortunately, we moved on to get everyone on TFS boards for thess multidiscipline teams.

Priority shifted in the middle of the board migration project. Some Dev team members got excited about what TFS can do and promised business users that TFS build service can solve their worsen code delivery issues caused by human mistakes. While TFS does provide the integration and automation, there are definitely more factors to consider when implementing an automated CI.

Branching & Merging

This is not a huge development team but most of the members do not have experience with branching and merging. So we start from scratch to gather current processes, pain points, workspace setup, and needs and wants.

Standardize build processes

From setting up build service (I also noted more details about how to decide the right build service) and cleanup some library referencing errors, standardize output files to manage config files.

Release Management

Not only the development team was doing the deployment in Production, The developer who changed the code is actually the one deploy the code to production. Because of this, deployment approval has to be carefully managed.

Intelligence

Prevent human errors like partial check-in, manual steps, and inconsist deployment flows were the original reasons for this initiative. So we do the work item association at check-in, label them by external ticket ID which is the system for Change Management so both developers and business users can clearly see the details for the delivery from TWA widgets.

Training

It is so great to partner with a reputable PM when rolling out TFS boards. We are basically doing both Agile process refreshment and TFS training at the same time. In addition, we also collect valuable user feedback during the roll-out training for both board Admin and users.

Migration

For some of the teams have been using other computer systems like Excel, SharePoint and other 3rd-party ticketing systems, it is just making more sense to help them migrating their records into TFS.

Reporting

Now that data are all set to go into TFS, we are ready to process them and get it out in a more meaningful ways. As far as tools go, there are some options being discussed.

Integration

Priority shifted again here as one might expect. Management is thinking about using different ticketing system for Change Management. Although it is still in its early stage, our leader wants us to prepare the integration between TFS and the new CM system. The goal is reduce the redundent data entry overhead between systems. I decide to use Web Hook as the service hook on the TFS side and is currently exploring to subscribe the other side’s web service.

Demonstration of Continuous Integrated SCM/ALM w/ TFS 2010 & Lab Management & MTM & SCVMM & …

  1. Prepare the virtual environment on a single laptop
  2. Explain this isolated virtual environment
  3. Show the target web site
  4. Remote to the web server and show the environment settings
  5. Damage the site (delete some files and change some IIS settings, etc.)
  6. Show the damaged site (and errors showed)
  7. Open 2 work items for the issue (one Bug and one Task) – One for velocity and one for burn down
  8. Show source code branches and explain briefly about the branching strategies
  9. Modify the page (put current date time on it to illustrate the changes)
  10. Check In, without associate any work items to show the error and check in policy
  11. Check in, associate a work item this time and explain what will happen next
  12. Check-In => Build => Virtual Env => Deploy => Automatic Tests => Notification
  13. Explain notification is handled by TFS event handling process
  14. TFS Event => SOAP message => Web Service => Folder Monitor => Event Handlers => Emails
  15. Explain utilization of MS Workflow + Activities implementation
  16. Show reports of Velocity and Burn down
  17. Show SharePoint portal for dashboard and Wiki
  18. Update work items’ Remaining Work and Assign To and show the linked changesets from history
  19. Check/Show the build progress
  20. Check emails through web interface (WOA)
  21. Emphasize again about the isolated domain setting (DC + Exchange +  TFS + VMs,…)
  22. When emails are received, show the “fixed” web site
  23. Show the recovered IIS settings
  24. Update/Close work items as they are passed by our QA
  25. Run web services to update DW & SSAS
  26. Show the updated burn down chart (velocity is grouped by date, we may not able to show it tight away unless modifying the report that way)
  27. Show some SCM specific reports
  28. Done – Q & A