Microsoft Office ने Source Depot से Git में माइग्रेट कैसे किया

• Microsoft Office ने लंबे समय तक अपने आंतरिक source management system Source Depot का उपयोग किया, लेकिन developer experience और तकनीकी नवाचार के लिए Git में बड़े पैमाने पर migration किया
• Source Depot में centralized architecture, धीमी branching, असुविधाजनक workflow जैसी सीमाएँ थीं, और Git में migration के लिए सैकड़ों engineers और कई वर्षों का काम लगा
• migration के दौरान VFS for Git जैसी नई तकनीक का विकास, मौजूदा build/test infrastructure का porting, और parallel system संचालन जैसे बड़े तकनीकी और संगठनात्मक चुनौतियों को पार किया गया
• सफल migration के लिए "Champion"-केंद्रित communication system, साहसी transparency, व्यावहारिक training, और तत्काल rollback strategy जैसे collaborative और human-centric approach पर जोर दिया गया
• migration के बाद onboarding time में कमी, Git preference में वृद्धि (89%), productivity improvement जैसे सकारात्मक परिणाम मिले, और बड़े तकनीकी बदलावों के लिए महत्वपूर्ण सबक सामने आए

---

Source Depot से Git तक: Microsoft Office के बड़े migration का अनुभव

developer productivity को अधिकतम करने की नई चुनौती

• developer productivity बढ़ाने का काम 'Multiplier work' है, और संगठन जितना बड़ा हो, इसका मूल्य उतना अधिक होता है
• Microsoft Office का Source Depot से Git migration इसका एक प्रतिनिधि उदाहरण था
• यह काम सिर्फ tool बदलने का मामला नहीं था, बल्कि सैकड़ों engineers, जटिल systems, और लंबे समय तक चलने वाला एक विशाल project था

Source Depot: उस दौर की source management कहानी

• 2000 के शुरुआती दशक में Microsoft, Perforce तकनीक पर आधारित अपने version control system Source Depot का संचालन करता था
• Source Depot में धीमी branching, centralization, लंबे code checkout time, और असुविधाजनक merge तरीका (Reverse/Forward Integrate) जैसी वजहों से काम की efficiency सीमित थी
• यह पूरे development infrastructure (build, release, workflow) के साथ गहराई से जुड़ा हुआ था, इसलिए इसे सरलता से बदला नहीं जा सकता था
• Microsoft Office के Git migration के लिए कई साल और सैकड़ों engineers की मेहनत लगी

OneNote से शुरुआत: migration की शुरुआत

• Office engineering organization में Source Depot को maintain और patch करने की लागत और “competitive technology” की ज़रूरत के कारण बड़े पैमाने पर Git migration का निर्णय लिया गया
• Office product suite में release cycle (कई महीने, half-yearly, monthly, insider) के अनुसार development schedule अलग-अलग थे, इसलिए लंबे समय तक Source Depot-Git parallel operation आवश्यक था
• Office version control consistency, build verification, और legacy test infrastructure का porting जैसे कार्य अनिवार्य चुनौती बनकर उभरे

Office का scale और communication strategy

• उस समय Office में 4,000 engineers मिलकर काम करते थे, इसलिए यह एक बेहद बड़ा संगठन था
• हर team में 'Developer Satisfaction Champion' नियुक्त किया गया, और teams को जोड़ने के लिए hub-spoke model के माध्यम से smooth feedback और communication structure तैयार किया गया
• लेखक OneNote के champion थे और उन्होंने इस बड़े migration के केंद्र में महत्वपूर्ण भूमिका निभाई

VFS for Git: विशाल codebase की सीमा को तोड़ना

• codebase इतना बड़ा था कि एक बार git clone करने के लिए 200GB से अधिक space चाहिए होता था, इसलिए GitHub के साथ मिलकर Virtual File System for Git (VFS for Git) विकसित किया गया
• VFS for Git केवल वही files लाने के तरीके पर काम करता था जिनकी वास्तव में ज़रूरत हो, जिससे basic Git की सीमाएँ पार की जा सकीं
• Microsoft Windows के साथ सहयोग करते हुए, version control system की industry-scale सीमाओं को पार करने का अनुभव मिला

migration के चरणबद्ध तरीके

चरण 1: समानांतर ब्रह्मांड (Parallel Universe)

• Source Depot और Git को real-time में synchronize करने वाली bridge service बनाई गई, और दोनों systems के mismatch तथा model difference (branch structure, changelist आदि) से जुड़ी समस्याओं को बार-बार सुधारते हुए आगे बढ़ा गया
• Office main/private branch-sync-build process को 24/7 automated system के रूप में चलाया गया
• तीन बार retry करने के बाद स्थिर रूप से काम करने वाला parallel system तैयार किया गया

चरण 2: equivalence verification

• सभी test suites को दोनों systems पर बार-बार चलाकर यह साबित किया गया कि build results पूरी तरह समान थे
• line ending, uppercase/lowercase, और test result format जैसी सूक्ष्म भिन्नताओं को कई महीनों तक debug करके ठीक किया गया
• 'Green across the board' (दोनों systems में सभी tests pass) हासिल होने के बाद, वास्तविक transition phase में जाने की तैयारी पूरी हुई

human-centric approach

multi-channel, repeated communication

• 4,000+ engineers और दर्जनों teams के schedule को समन्वित करने के लिए, हर team के champion के साथ intensive communication structure बनाया गया
• महत्वपूर्ण घोषणाएँ कम से कम 3 बार (email, Teams, wiki, meeting आदि) दोहराकर साझा की गईं ताकि confusion कम हो
• समस्या आने पर तुरंत और transparent information sharing के ज़रिए trust बनाया गया

Git adoption training और adaptation

• 10 वर्षों तक Source Depot के आदी engineers के लिए hands-on training environment और migration commands guide जैसी चरणबद्ध learning व्यवस्था बनाई गई
• practical video library जैसी सामग्रियों से real scenario-based learning उपलब्ध कराई गई
• इसका मकसद सिर्फ anxiety कम करना और capability बढ़ाना नहीं था, बल्कि मौजूदा workflow के अनुकूलन में मदद देना भी था

rollback strategy और safety mechanism

• वास्तविक transition के समय Director को एक 'red button' दिया गया, ताकि गंभीर समस्या होने पर कभी भी तुरंत rollback किया जा सके
• Source Depot के कुछ पुराने records को लंबे समय तक सुरक्षित रखा गया, ताकि पुराना development history सुरक्षित बना रहे

परिणाम और प्रमुख उपलब्धियाँ

• migration के बाद onboarding time 50% कम हुआ, Git preference 89% दर्ज की गई, build performance बेहतर हुई, और code review efficiency व collaboration बढ़ने जैसी productivity improvements दिखाई दीं
• engineers ने industry में transfer की जा सकने वाली skills सीखने को सकारात्मक रूप से आंका
• नए लोगों को जल्दी productive बनाने की क्षमता भी बढ़ी

बड़े migration से मिले मुख्य सबक

• सिर्फ तकनीक ही नहीं, बल्कि people-centric communication में भी अपेक्षा से कहीं अधिक निवेश करना पड़ता है, तभी सफलता की संभावना बढ़ती है
• parallel system बनाना, पूर्ण equivalence साबित करना, शुरू से मजबूत rollback design रखना, और key people (champions) पर ज़ोर देना महत्वपूर्ण था
• satisfaction जैसे qualitative metrics को साथ मापना अनिवार्य है, और बदलाव की प्रक्रिया में organizational stability और psychological safety की भावना अहम होती है
• बड़े बदलाव का सार पूरे संगठन में लचीले और व्यवस्थित change management में है

निष्कर्ष और आगे का उपयोग

• Office का Git migration कई वर्षों की तैयारी और कई महीनों के execution से पूरा हुआ एक ऐतिहासिक project था
• अंततः यह हज़ारों लोगों के कामकाजी जुड़ाव को बनाए रखते हुए संगठनात्मक बदलाव को सफलतापूर्वक आगे बढ़ाने का उदाहरण बन गया
• cloud migration, monolithic architecture decomposition, framework upgrade जैसे अन्य बड़े बदलावों में भी parallel verification, repeated communication, और fast rollback design समान रूप से लागू किए जा सकते हैं
• तकनीकी विवरण (build infrastructure, offline/contract issues आदि) को यहाँ विस्तार से नहीं लिया गया, लेकिन बड़े तकनीकी बदलावों के लिए strategic और organizational approach ही सबसे महत्वपूर्ण सीख है

[ndrgrd]

अगर आप बहुत सारी binary files संभालते हैं, तो git शायद उपयुक्त न हो, लेकिन code-केंद्रित repository के लिए git काफ़ी लगता है।

[rtyu1120]

यह MS के अंदर भी बड़ा बदलाव रहा होगा, लेकिन इसकी वजह से partial clone, sparse checkout जैसी सुविधाएँ और Scalar जैसे टूल्स बाहर भी सार्वजनिक होकर इस्तेमाल के लिए उपलब्ध हुए—यह भी एक अच्छा असर लगता है, haha

[GN⁺]

Hacker News राय

• हमेशा अच्छा लगता है जब इस पुराने किस्से को नए तरीके से सुनाने वाला लेख पढ़ने को मिलता है। TFA में यह ज़रूर कहा गया है कि “पूरे Office repository को लाने में कुछ घंटे लगे”, लेकिन यह बात लगभग छूट जाती है कि git में VFS जैसे नए file system के बिना ऐसा काम लगभग असंभव था। Perforce में उपयोगकर्ता सिर्फ वही हिस्से checkout कर सकते थे जिनकी उन्हें ज़रूरत हो, इसलिए संभवतः ज़्यादातर Source Depot उपयोगकर्ता भी हर बार पूरा Office app नहीं लाते थे, बल्कि केवल आवश्यक भाग ही लेते थे। VFS git में सिर्फ ज़रूरी objects डाउनलोड करवा कर इस अंतर को कम करता है। Perforce/Source Depot उस समय centralised VCS के रूप में बहुत मजबूत विकल्प थे, लेकिन अब लगता है कि समय बदल चुका है।
  • यह भी बताया गया है कि Perforce में भी VFS जैसी, ज़रूरत पड़ने पर ही files लाने वाली अपनी तकनीक बनाने वाली कंपनियाँ हैं। यह खास तौर पर game development में महत्वपूर्ण है, जहाँ text files के साथ बड़े binary source assets भी रखे जाते हैं। मुझे लगता है कि इसकी जड़ें उसी तकनीक से जुड़ी हैं जिसका इस्तेमाल Windows में built-in remote drive program करता है। व्यक्तिगत रूप से मैं अब भी ऐसा server-based VCS चाहता हूँ जिसमें पूरी कंपनी का source रखा जा सके, लेकिन local पर पूरी history replicate करने की ज़रूरत न हो। फिर भी कई devices के बीच ad hoc collaboration के लिए git काफ़ी उपयोगी है, इसलिए अभी तक मुझे central server और CI/CD pipeline तक खड़ी करने की ज़रूरत महसूस नहीं हुई। git में stash, hunk-level stage, interactive rebase जैसी कई workflows मुझे बहुत पसंद हैं।
  • हमारी कंपनी अब भी perforce इस्तेमाल करती है, और अफ़सोस की बात है कि अब perforce किसी को पसंद नहीं आता। मैंने खुद देखा है कि जैसे ही नए लोगों से कहते हैं, “हम git इस्तेमाल नहीं करते”, उनकी आँखों की चमक गायब हो जाती है।
  • VFS, Perforce को पूरी तरह replace नहीं कर सकता। खास तौर पर यह रेखांकित किया गया है कि ज़्यादातर AAA game companies अब भी Perforce इस्तेमाल करती हैं। asset files पर lock लगाना ज़रूरी होता है ताकि दो लोग एक साथ बदलाव करके ऐसी स्थिति न बना दें जिसे merge ही न किया जा सके, और इससे किसी artist के काम को फेंकना पड़े, ऐसी समय-बर्बादी भी कम होती है।
  • सच कहूँ तो यह समझ नहीं आता कि git अब तक repository tree के सिर्फ किसी खास हिस्से को चुनकर checkout करने की सुविधा क्यों नहीं देता। मुझे लगता है कि object files वगैरह को समझने वाली किसी बीच की service जोड़कर इसे आसानी से बढ़ाया जा सकता है।
• 2016 में Microsoft internship के दौरान Source Depot को support करने वाला एक automatic code reviewer बनाते समय, मुझे Source Depot क्या है यह भी नहीं पता था, और मैंने लगभग एक हफ्ता इस feature पर लगा दिया था (https://austinhenley.com/blog/featurestheywanted.html)। तब भी बहुत से developers Source Depot इस्तेमाल कर रहे थे। अब सब लोग git पर चले गए हैं या नहीं, यह जानने की उत्सुकता है।
  • मुझे CodeFlow आज भी हर दिन याद आता है। वह सचमुच शानदार tool था।
  • अब भी बहुत से क्षेत्रों में Source Depot सक्रिय रूप से इस्तेमाल हो रहा है। Source Depot commands और environment settings मुझे हमेशा तनाव में डाल देते हैं।
  • रोज़मर्रा का ज़्यादातर काम अब git में ही हो जाता है।
• 90 के दशक में खुद vss(Visual SourceSafe) इस्तेमाल करने वाले के रूप में, यह देखकर हैरानी हुई कि इस लेख में उसका ज़िक्र तक नहीं है। Visual SourceSafe Microsoft का अपना source version control protocol था, जबकि Source Depot, Perforce से license लेकर इस्तेमाल किया गया अलग सिस्टम था।
  • VSS(Visual SourceSafe) Raleigh की One Tree Software को acquire करके मिला था, और उसका नाम “SourceSafe” से बदलकर “Visual SourceSafe” कर दिया गया, फिर उसे Visual C, Visual Basic आदि के साथ bundle किया गया। उससे पहले “Microsoft Delta” नाम का एक version control product बेचा जाता था, जो महँगा था, गुणवत्ता में कमज़ोर था, और NT पर तो support भी नहीं करता था। One Tree acquisition से आए लोगों में Brian Harry भी थे, जिन्होंने बाद में Team Foundation Version Control(TFS) को lead किया। इसमें SQL Server को repository के रूप में इस्तेमाल किया गया, जिससे VSS की तुलना में manageability और reliability काफ़ी बेहतर हुई। लगता है Brian Harry अब retire हो चुके हैं और उनका blog भी अब update नहीं होता। VSS इस्तेमाल करते हुए जो बात याद रहती है, वह यह है कि network file locking SMB के ज़रिए होती थी, इसलिए यह बार-बार होने वाली network errors के प्रति बहुत संवेदनशील था, और repository अक्सर corrupt हो जाती थी। इसी वजह से हर रात तड़के recovery batch job चलानी पड़ती थी ताकि रात में auto-repair हो जाए, क्योंकि सुबह तक उसे इस्तेमाल लायक होना ही चाहिए था।
  • 90 के दशक में VSS इस्तेमाल करने के अनुभव से कहूँ तो, team के साथ काम करते समय यह लगभग एक बुरे सपने जैसा था, और मेरी जानकारी के अनुसार Microsoft ने भी इसे अंदरूनी तौर पर लगभग इस्तेमाल नहीं किया।
  • 90 के दशक में जब मैं अकेले development करता था, तब VSS मेरे लिए किसी नए संसार जैसा था। बाद में graduate school में दूसरे VCS(RCS, CVS आदि) देखे। 2004 में Microsoft join करने पर किसी ने मुझे बताया था कि VSS असुरक्षित है और आसानी से corrupt हो जाता है। यह कितना सच था, पता नहीं, लेकिन इतना तय है कि कंपनी में VSS कोई विकल्प ही नहीं था।
• मैं Microsoft के XNS से TCP/IP migration के समय टीम में था। यह काम उम्मीद से कम जटिल था, लेकिन इससे मिलते-जुलते सबक ज़रूर मिले। MSMAIL से Exchange पर जाना वाकई बहुत कठिन था।
  • मुझे याद है कि कभी “Exchange: The Most Feared and Loathed Team in Microsoft” लिखा हुआ license plate frame देखा था; सोचता हूँ क्या यह उसी दौर के अनुभवों की वजह से था। 20 साल पुरानी बात है, इसलिए सही शब्द याद नहीं हैं।
• “Authenticity mattered more than production value” वाली बात दिल को छू गई। Microsoft के एक छोटे product line में काम कर चुके पूर्व कर्मचारी के रूप में, जहाँ commute से ठीक पहले (2015 में) Source Depot से Git में बदलाव शुरू हुआ था, मैं पूरी तरह समझ सकता हूँ कि ऐसे काम में कितनी मेहनत लगती है। यह सचमुच शानदार उपलब्धि है।
  • मुझे भी यक़ीन नहीं होता कि मैं यह सब होते हुए देख चुका हूँ। दिल से धन्यवाद।
• 2000 के दशक की शुरुआत में Microsoft जिस स्थिति से जूझ रहा था, उसे देखें तो Windows बेहद जटिल हो चुका था और लाखों lines of code को version control की ज़रूरत थी, लेकिन git था ही नहीं और SVN भी बस बढ़ना शुरू ही हुआ था। सोचता हूँ क्या Microsoft ने 1998 में विकसित और 2000 में public किए गए BitKeeper जैसे commercial products पर गंभीरता से विचार किया था। शायद उस समय Perforce जैसे centralised systems ही मुख्यधारा में थे, और BitKeeper जैसे distributed systems अजनबी लगते थे या उनके पर्याप्त proven examples नहीं थे।
  • उस समय VSS(Visual SourceSafe) था, और बाद में TFVC आया।
• मेरे जैसे beginner engineer को Source Depot का रहस्य समझाने वाले dev leads का मैं आभारी हूँ। जब Source Depot की बनावट ठीक से समझ में आई, तो सचमुच आँखें खुल गईं। मेरी dependency सिर्फ WinCE और IE पर थी, इसलिए clone में केवल 20 मिनट लगे; कई दिन नहीं लगे, इसके लिए मैं खुद को भाग्यशाली मानता हूँ। जिन लोगों ने मदद की उनके नाम तो याद नहीं, लेकिन नए लोगों को जल्दी काम शुरू करने लायक बनाने की जो भावना थी, वही मैं आज अपनी team में भी आगे बढ़ाने की कोशिश करता हूँ।
• ज़्यादातर लोग git adoption को technical जीत के रूप में याद करते हैं, लेकिन असली बदलाव यह था कि individual developers को अपने workflow पर खुद नियंत्रण मिल गया। अब sync window का इंतज़ार नहीं करना पड़ता, न branch access के लिए lead से अनुरोध करना पड़ता है। अब सब लोग बिना एक-दूसरे से टकराए आज़ादी से तेज़ी से काम कर सकते हैं। मेरा मज़बूत impression है कि इस बदलाव का असर productivity dashboard से कहीं ज़्यादा टीम के माहौल पर पड़ा। git सिर्फ एक tool नहीं था; उसने development loop पर भरोसा भी बदल दिया।
• सोचता हूँ Microsoft ने अंदरूनी तौर पर Visual SourceSafe को आख़िर कब छोड़ा। मेरा मानना है कि इसे पहले ही बंद कर देना चाहिए था ताकि बाहर लोग इसे इस्तेमाल करते न रहते।
  • मेरा अनुमान है कि ज़्यादातर teams वास्तव में VSS इस्तेमाल नहीं करती थीं। Microsoft में काम करते समय हमारी team Source Depot इस्तेमाल करती थी। उस समय TFS का भी अनुभव हुआ, जो मुझे खास पसंद नहीं आया। फिर भी Source Depot इस्तेमाल करने के बाद तो TFS की याद आने लगी।
  • यह भी संदेह है कि Microsoft ने VSS को कभी आंतरिक रूप से मुख्य उपयोग में लिया भी था या नहीं। अगर सच में लिया होता, तो शायद इसे इतनी कमज़ोर स्थिति में बाहर जारी नहीं किया जाता। TFS ऐसा अनुभव था जिसे समझना मुश्किल था, और वह अंदर हो या बाहर, अच्छा नहीं लगा।
  • शायद यह 2000 के आसपास की बात होगी। मेरी जानकारी में केवल .NET ही ऐसा project था जिसने इसका इस्तेमाल किया, और वह भी तब तक Source Depot पर जा चुका था।
  • प्रतिक्रिया यह थी कि Microsoft SourceSafe नाम की कोई चीज़ है, यह भी पता नहीं था।
• OneNote shallow clone के 200GB होने की बात समझ में नहीं आती।
  • स्पष्टीकरण यह है कि वह OneNote नहीं, बल्कि पूरे Office का shallow clone था।
  • संभवतः उसमें video या बड़े binary files शामिल थे।