Skip to main content
Yutaka OSADA

Yutaka OSADA

Japan

C#, .NET, Azure, Azure DevOps, GitHub

Community Contributions

Speaker at - BuriKaigi 2026 "GitHub-to-GitHub migrations and how to make tool decisions with a clear view of “what cannot be migrated.”"

- Description - Delivered an accepted conference talk at BuriKaigi 2026 (25 mins, 15:00–15:25 JST, Jan 10, 2026) on the current state of GitHub-to-GitHub migrations and how to make tool decisions with a clear view of “what cannot be migrated.” - Presented a practical migration framework and key takeaways of GitHub Enterprise Importer (GEI), grounded in real-world enterprise scenarios such as trial → production and regular accounts → EMU (Enterprise Managed Users) transitions. - Clarified decision criteria for migratable vs. non-migratable items and introduced an implementation-oriented analysis phase using tools like GitHub Migration Analyzer (OSS, customizable) and gh-repo-stats (CLI extension) to understand repository attributes and migration risk. - Shared a repeatable checklist for governance-safe migration planning in the Copilot era—covering tool selection, assessment outputs interpretation, and small-start migration examples that teams can apply immediately. - Session page: [https://fortee.jp/burikaigi-2026/proposal/05741d76-a77a-4c31-a3ee-f7001cbcc561](https://fortee.jp/burikaigi-2026/proposal/05741d76-a77a-4c31-a3ee-f7001cbcc561) - Slide link: [https://speakerdeck.com/yutakaosada/20260110-githubyi-xing-noxian-zai-di-turuxuan-ding-to-yi-senaimono-nojian-ji-me](https://speakerdeck.com/yutakaosada/20260110-githubyi-xing-noxian-zai-di-turuxuan-ding-to-yi-senaimono-nojian-ji-me)

Speaking (conference/usergroups) / 01-11-2026

Blogpost – Understanding Azure Developer CLI by building an azd project from scratch

This post explains what Azure Developer CLI (azd) actually does by creating an azd project from scratch (no templates). It containerizes a .NET 8 Minimal API, builds locally, pushes the image to Azure Container Registry, and runs it on Azure App Service (Linux / custom container) using Managed Identity + AcrPull. The key learning is how `azure.yaml` (services/hooks) and `infra/` (Bicep) work together: Bicep outputs are exposed as azd environment variables, and a `postprovision` hook updates the Web App to the newly pushed immutable image tag and restarts it. The article was also featured (“Picked up”) by Zenn’s official account. ([X (formerly Twitter)][2]) [1]: https://zenn.dev/yutakaosada/articles/41a99b7ed9e435 [2]: https://x.com/zenn_dev/status/2008476909685141511

Blogpost / 01-01-2026

Blogpost – Azure DevOps Marketplace Ranking (2025): Top Extensions by Installs

* Description * Published the 2025 edition of an Azure DevOps Marketplace ranking, continuing the annual roundup from the previous year. * Surveyed the Visual Studio Marketplace as of Dec 24, 2025, noting that Azure DevOps has ~3,000 extensions available and that install counts change over time. * For each major category (Boards / Repos / Pipelines / Artifacts / Test Plans), selected the Top 5 extensions by “Installs” and recorded key metadata such as *Installs, Released on, and Last updated*. * Highlighted notable trends in 2025 adoption: * Security & code quality tools remained strong (e.g., SARIF integrations, SonarQube). * IaC & automation continued to grow (e.g., Terraform, token replacement utilities). * Agile/ways of working support gained traction (e.g., Retrospectives moving up in rank). * Included practical guidance: start with widely adopted extensions—especially Microsoft/Microsoft DevLabs and established integrations—to quickly improve productivity and governance in real Azure DevOps operations.

Blogpost / 12-24-2025

Blogpost – Exporting a GitHub Team Member List to CSV with Python + GitHub API

* Description * Introduced a practical Python script to export members of a specific GitHub Team into a CSV file using the GitHub REST API, addressing a common gap: GitHub’s UI can export org-wide members, but not team-only members. * Motivated by real operational needs such as review team rosters, project team inventory, and especially GitHub Copilot license governance where many organizations assign Copilot licenses via team membership. * Implemented a minimal, reusable approach using `GET /orgs/{org}/teams/{team_slug}/members` with pagination (`per_page=100`) and token-based auth via the `GITHUB_TOKEN` environment variable (PAT with at least `read:org`). * Output CSV includes core fields (`login`, `id`, `type`, `html_url`) to support sharing with HR/procurement and license audits. * Shared extension ideas: export multiple teams in one run and optionally fetch team role (member/maintainer) via `GET /orgs/{org}/teams/{team_slug}/memberships/{username}`.

Blogpost / 12-08-2025

Blogpost – Inventorying Azure DevOps with gh-ado2gh and AI (for Migration Readiness & Cleanup)

* Description * Explained a practical first step for Azure DevOps → GitHub consideration: “source environment assessment”—understanding how many orgs/projects/repos/pipelines exist before planning any migration or cleanup. * Introduced `gh-ado2gh` (the ADO2GH extension for GitHub CLI, part of GitHub Enterprise Importer) and demonstrated how to generate an inventory with: `gh ado2gh inventory-report`. * Walked through how to read the generated CSVs—`orgs.csv`, `team-projects.csv`, `repos.csv`, and `pipelines.csv`—and what each key column reveals (scale, activity, repo size, PR volume, pipeline footprint, last push date, etc.). * Shared human-friendly review heuristics (health-check view, identifying “heavy” projects, finding stale repos, and spotting repos with high pipeline complexity) to decide whether to migrate, keep, or archive. * Added a lightweight AI angle: feed `repos.csv` into Copilot/ChatGPT to score and classify repositories by *Size / Activity / Complexity*, then group them into migration “waves” (Wave 1–3) plus manual review—letting humans focus on business context and ownership decisions. * Highlighted that this approach is useful even without migration plans—as an Azure DevOps “health check” to visualize drift and sprawl.

Blogpost / 12-04-2025

OSS – Support Ticket Management & Notifications with Azure Boards + Dapr

* Description * Proposed an approach to consolidate “support tickets vs. development issues” by using Azure Boards as the primary support ticketing hub, not just a generic task board. * Designed a dedicated support workflow by creating an inherited custom process and a new work item type (Support Ticket) with support-specific states (e.g., *Triage*, *Waiting*) and custom fields (e.g., customer/tenant identifiers, severity, due date, category). * Built a fully customizable real-time notification pipeline: Azure DevOps Service Hooks → Azure Service Bus → Dapr on Azure Container Apps → Logic Apps → Teams/Slack, generating Adaptive Cards in code so the message format and routing can evolve without being constrained by default integrations. * Automated scheduled reporting with WIQL + Dapr Cron: reuse saved Azure Boards queries via REST API and send daily/weekly summaries (e.g., overdue tickets, assigned-to-me, closed counts) to collaboration channels. * Discussed operational/security trade-offs (e.g., choosing Logic Apps over direct Microsoft Graph calls to avoid heavy permission and review overhead in many enterprises). Link:https://zenn.dev/yutakaosada/articles/78f2f7ccb00b3a

Open source project / 12-02-2025

Blogpost – Support Ticket Management & Notifications with Azure Boards + Dapr

* Description * Proposed an approach to consolidate “support tickets vs. development issues” by using Azure Boards as the primary support ticketing hub, not just a generic task board. * Designed a dedicated support workflow by creating an inherited custom process and a new work item type (Support Ticket) with support-specific states (e.g., *Triage*, *Waiting*) and custom fields (e.g., customer/tenant identifiers, severity, due date, category). * Built a fully customizable real-time notification pipeline: Azure DevOps Service Hooks → Azure Service Bus → Dapr on Azure Container Apps → Logic Apps → Teams/Slack, generating Adaptive Cards in code so the message format and routing can evolve without being constrained by default integrations. * Automated scheduled reporting with WIQL + Dapr Cron: reuse saved Azure Boards queries via REST API and send daily/weekly summaries (e.g., overdue tickets, assigned-to-me, closed counts) to collaboration channels. * Discussed operational/security trade-offs (e.g., choosing Logic Apps over direct Microsoft Graph calls to avoid heavy permission and review overhead in many enterprises). * Code / IaC (Bicep + C#): [https://github.com/yutaka-art/azdo-ticket-management](https://github.com/yutaka-art/azdo-ticket-management)

Blogpost / 12-02-2025

Blogpost – Putting Developers in the Spotlight: Building a GitHub Contribution Dashboard

* Description * Built a dashboard that visualizes public GitHub activity of members in a specific GitHub Organization—commits, pull requests, and PR reviews—and presents them as rankings and charts. * Key design choice: the dashboard is not limited to repositories under the Organization; it aggregates each member’s overall public GitHub contributions, enabling teams to recognize “invisible” OSS and cross-repo impact. * Implemented with .NET 8 and ASP.NET Core Razor Components (server-interactive), using GitHub GraphQL API v4 via `GraphQL.Client`. * Addressed scalability and rate limits with in-memory caching, SemaphoreSlim to serialize expensive refresh operations, paged org member retrieval, batched contribution queries, retry logic, and throttling delays. * Added Application Insights telemetry from early development to observe API latency, retries, and runtime behavior. * Discussed the “fun vs. risk” of individual metrics—how a ranking can easily become a surveillance tool—and proposed guardrails (use it for conversation and recognition, not formal evaluation). * Code / OSS: [https://github.com/yutaka-art/github-contribution-rankings](https://github.com/yutaka-art/github-contribution-rankings)

Blogpost / 12-01-2025

Related Stars