Devops | The .NET Blog

Azure DevOps Server अप्रैल 2026 पैच — PR Completion फिक्स और Security अपडेट

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

यह पोस्ट स्वचालित रूप से अनुवादित है। मूल के लिए, यहाँ क्लिक करें.

self-hosted Azure DevOps Server चला रही teams के लिए एक ज़रूरी सूचना: Microsoft ने अप्रैल 2026 के लिए Patch 3 release किया है जिसमें तीन targeted fixes हैं।

क्या ठीक किया गया

Pull request completion failures — work item auto-completion के दौरान एक null reference exception से PR merges fail हो सकती थीं। अगर आपको random PR completion errors आती थीं, तो संभवतः यही कारण था
Sign-out redirect validation — sign-out के दौरान संभावित malicious redirects को रोकने के लिए बेहतर validation। यह एक security fix है जिसे जल्दी लागू करना उचित है
GitHub Enterprise Server PAT connections — GitHub Enterprise Server में Personal Access Token connections बनाना टूटा हुआ था, अब यह ठीक हो गया है

Update कैसे करें

Patch 3 download करें और installer चलाएं। यह verify करने के लिए कि patch लागू हुआ है:

<patch-installer>.exe CheckInstall

अगर आप Azure DevOps Server on-premises चला रहे हैं, तो Microsoft दृढ़ता से सुरक्षा और विश्वसनीयता दोनों के लिए नवीनतम patch पर रहने की सलाह देता है। पूरी जानकारी के लिए release notes देखें।

Agentic Platform Engineering हकीकत बन रही है — Git-APE दिखाता है कैसे

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

यह पोस्ट स्वचालित रूप से अनुवादित है। मूल के लिए, यहाँ क्लिक करें.

Platform engineering उन terms में से एक रही है जो conference talks में बहुत अच्छी लगती है, लेकिन आमतौर पर इसका मतलब होता है “हमने एक internal portal और एक Terraform wrapper बनाया।” असली वादा — self-service infrastructure जो वास्तव में safe, governed और fast हो — हमेशा कुछ कदम दूर रही है।

Azure team ने अभी अपनी agentic platform engineering series का Part 2 प्रकाशित किया, और यह पूरी तरह hands-on implementation के बारे में है। वे इसे Git-APE कहते हैं (हाँ, acronym जानबूझकर है), और यह एक open-source project है जो GitHub Copilot agents plus Azure MCP servers का उपयोग करके natural-language requests को validated, deployed infrastructure में बदलता है।

Git-APE वास्तव में क्या करता है

मूल विचार: developers को Terraform modules सीखने, portal UIs navigate करने, या platform team को tickets file करने की बजाय, वे एक Copilot agent से बात करते हैं। Agent intent को समझता है, Infrastructure-as-Code generate करता है, उसे policies के खिलाफ validate करता है, और deploy करता है — सब VS Code के अंदर।

यहाँ setup है:

git clone https://github.com/Azure/git-ape
cd git-ape

VS Code में workspace खोलें, और agent configuration files GitHub Copilot द्वारा auto-discovered हो जाती हैं। आप agent के साथ directly interact करते हैं:

@git-ape deploy a function app with storage in West Europe

Agent Azure services के साथ interact करने के लिए Azure MCP Server का उपयोग करता है। VS Code settings में MCP configuration specific capabilities enable करता है:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

यह क्यों मायने रखता है

जो लोग Azure पर build कर रहे हैं, उनके लिए यह platform engineering की conversation को “हम एक portal कैसे बनाएं” से “हम अपने guardrails को APIs के रूप में कैसे describe करें” की ओर shift करता है। जब आपके platform का interface एक AI agent हो, तो आपके constraints और policies की गुणवत्ता ही product बन जाती है।

Part 1 blog ने theory रखी: well-described APIs, control schemas, और explicit guardrails platforms को agent-ready बनाते हैं। Part 2 actual tooling ship करके साबित करता है कि यह काम करता है। Agent अंधाधुंध resources generate नहीं करता — यह best practices के खिलाफ validate करता है, naming conventions का सम्मान करता है, और आपके organization की policies लागू करता है।

Clean-up भी उतनी ही आसान है:

@git-ape destroy my-resource-group

मेरी राय

सच कहूँ तो — यह specific tool से ज़्यादा pattern के बारे में है। Git-APE खुद एक demo/reference architecture है। लेकिन underlying idea — agents आपके platform का interface, MCP protocol, GitHub Copilot host — यही वह जगह है जहाँ enterprise developer experience जा रही है।

अगर आप एक platform team हैं जो देख रहे हैं कि अपने internal tooling को agent-friendly कैसे बनाएं, तो इससे बेहतर कोई starting point नहीं है। और अगर आप एक .NET developer हैं जो सोच रहे हैं कि यह आपकी दुनिया से कैसे जुड़ता है: Azure MCP Server और GitHub Copilot agents किसी भी Azure workload के साथ काम करते हैं। आपकी ASP.NET Core API, आपका .NET Aspire stack, आपके containerized microservices — यह सब एक agentic deployment flow का target हो सकता है।

अंत में

Git-APE agentic platform engineering का एक प्रारंभिक लेकिन ठोस रूप है। repo clone करें, demo आज़माएं, और सोचना शुरू करें कि आपके platform की APIs और policies को एक agent द्वारा safely उपयोग किए जाने के लिए कैसा दिखना होगा।

walkthrough और video demos के लिए पूरा post पढ़ें।

Azure DevOps ने आखिरकार वो Markdown Editor UX ठीक किया जिसकी सबको शिकायत थी

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

यह पोस्ट स्वचालित रूप से अनुवादित है। मूल के लिए, यहाँ क्लिक करें.

अगर आप Azure Boards इस्तेमाल करते हैं, तो शायद आपने यह अनुभव किया होगा: आप किसी work item की description पढ़ रहे हैं, शायद acceptance criteria review कर रहे हैं, और गलती से double-click हो जाती है। बस — आप edit mode में चले जाते हैं। आप कुछ edit करना नहीं चाहते थे। आप बस पढ़ रहे थे।

Dan Hellem ने इस fix की घोषणा की, और यह उन बदलावों में से एक है जो सुनने में तो छोटा लगता है लेकिन वास्तव में आपकी रोज़ाना की workflow से असली परेशानी दूर करता है।

क्या बदला

work item text fields के लिए Markdown editor अब default रूप से preview mode में खुलता है। आप content पढ़ और उसके साथ इंटरैक्ट कर सकते हैं — links follow कर सकते हैं, formatting review कर सकते हैं — बिना गलती से edit mode में जाने की चिंता किए।

जब आप वास्तव में edit करना चाहते हैं, तो field के ऊपर edit icon पर क्लिक करें। जब काम हो जाए, तो explicitly preview mode पर वापस आ जाएं। सरल, जानबूझकर, और अनुमानित।

बस इतना ही। यही बदलाव है।

यह जितना लगता है उससे ज़्यादा मायने क्यों रखता है

इस पर community feedback thread काफी लंबा था। double-click-to-edit का behavior जुलाई 2025 में Markdown editor के साथ आया था, और शिकायतें लगभग तुरंत शुरू हो गईं। समस्या केवल गलत edits तक सीमित नहीं थी — पूरा interaction अप्रत्याशित लगता था। आपको कभी पता नहीं चलता था कि click करने से read होगा या edit।

जो teams Azure Boards के साथ sprint planning, backlog grooming, या code review करती हैं, उनके लिए इस तरह की micro-friction जमा होती रहती है। हर गलत edit mode entry एक context switch है। हर “रुको, क्या मैंने कुछ बदला?” वाला पल ध्यान की बर्बादी है।

नया default सबसे आम interaction pattern का सम्मान करता है: आप work items को edit करने से कहीं ज़्यादा बार पढ़ते हैं।

Rollout की स्थिति

यह पहले से ही कुछ customers के लिए rollout हो रहा है और अगले दो से तीन हफ्तों में सभी के लिए उपलब्ध हो जाएगा। अगर आपको अभी नहीं दिख रहा, तो जल्द ही दिखेगा।

निष्कर्ष

हर सुधार को headline feature नहीं होना चाहिए। कभी-कभी सबसे अच्छा update बस कुछ परेशान करने वाली चीज़ को हटाना होता है। यह उन्हीं में से एक है — एक छोटा UX fix जो Azure Boards को उन लोगों के लिए कम कठिन बनाता है जो बस शांति से अपने work items पढ़ना चाहते हैं।

Azure DevOps MCP Server Microsoft Foundry में आया: आपके AI Agents के लिए इसका क्या मतलब है

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

यह पोस्ट स्वचालित रूप से अनुवादित है। मूल के लिए, यहाँ क्लिक करें.

MCP (Model Context Protocol) इन दिनों बहुत चर्चा में है। अगर आप AI agent ecosystem को follow कर रहे हैं, तो आपने शायद देखा होगा कि MCP servers हर जगह दिखने लगे हैं — agents को एक मानकीकृत protocol के ज़रिए बाहरी tools और services के साथ interact करने की क्षमता देते हैं।

अब Azure DevOps MCP Server Microsoft Foundry में उपलब्ध है, और यह उन integrations में से एक है जो आपको व्यावहारिक संभावनाओं के बारे में सोचने पर मजबूर करती है।

यहाँ वास्तव में क्या हो रहा है

Microsoft ने Azure DevOps MCP Server को public preview के रूप में पहले ही release किया था — वह MCP server ही है। नया यह है कि Foundry integration आई है। अब आप अपने Foundry agents में tool catalog से सीधे Azure DevOps MCP Server जोड़ सकते हैं।

जो Foundry से परिचित नहीं हैं उनके लिए: यह Microsoft का unified platform है जो बड़े पैमाने पर AI-powered applications और agents बनाने और manage करने के लिए है। Model access, orchestration, evaluation, deployment — सब एक ही जगह।

इसे Setup करना

Setup करना आश्चर्यजनक रूप से सीधा है:

अपने Foundry agent में जाएं Add Tools > Catalog
“Azure DevOps” खोजें
Azure DevOps MCP Server (preview) चुनें और Create पर क्लिक करें
अपना organization नाम डालें और connect करें

बस इतना। आपके agent को अब Azure DevOps tools तक access मिल गई।

आप अपने agent की access को control कर सकते हैं

यहाँ वो हिस्सा है जो मुझे पसंद आया: आप all-or-nothing approach तक सीमित नहीं हैं। आप specify कर सकते हैं कि आपके agent के लिए कौन से tools उपलब्ध हों। तो अगर आप चाहते हैं कि वो केवल work items पढ़े लेकिन pipelines को न छुए, तो आप उसे configure कर सकते हैं। Principle of least privilege, अपने AI agents पर लागू।

यह enterprise scenarios के लिए मायने रखता है जहाँ आप नहीं चाहते कि एक agent गलती से deployment pipeline trigger कर दे क्योंकि किसी ने उससे “release में मदद करो” कहा।

.NET teams के लिए यह क्यों दिलचस्प है

सोचिए यह व्यवहार में क्या enable करता है:

Sprint planning assistants — agents जो work items pull कर सकते हैं, velocity data analyze कर सकते हैं, और sprint capacity suggest कर सकते हैं
Code review bots — agents जो आपके PR context को समझते हैं क्योंकि वे वास्तव में आपके repos और linked work items पढ़ सकते हैं
Incident response — agents जो work items create कर सकते हैं, recent deployments query कर सकते हैं, और bugs को recent changes से correlate कर सकते हैं
Developer onboarding — “मुझे किस पर काम करना चाहिए?” का जवाब actual project data पर आधारित होगा

जो .NET teams पहले से CI/CD pipelines और project management के लिए Azure DevOps use कर रही हैं, उनके लिए एक AI agent का सीधे उन systems के साथ interact करना useful automation की दिशा में एक महत्वपूर्ण कदम है।

बड़ी MCP तस्वीर

यह एक बड़े trend का हिस्सा है: MCP servers AI agents के बाहरी दुनिया से interact करने का मानक तरीका बनते जा रहे हैं। हम GitHub, Azure DevOps, databases, SaaS APIs — सब के लिए MCP servers देख रहे हैं — और Foundry वह hub बनता जा रहा है जहाँ ये सभी connections एक साथ आते हैं।

अगर आप .NET ecosystem में agents बना रहे हैं, तो MCP पर ध्यान देना ज़रूरी है। Protocol मानकीकृत है, tooling mature हो रहा है, और Foundry integration इसे manually server connections wire किए बिना accessible बनाती है।

निष्कर्ष

Foundry में Azure DevOps MCP Server preview में है, इसलिए यह evolve होता रहेगा। लेकिन core workflow solid है: connect करें, tool access configure करें, और अपने agents को आपके DevOps data के साथ काम करने दें। अगर आप पहले से Foundry ecosystem में हैं, तो यह कुछ clicks की दूरी पर है। इसे try करें और देखें कि आप कौन से workflows बना सकते हैं।

पूरी setup और अधिक जानकारी के लिए official announcement देखें।