Microsoft Office'un Source Depot'tan Git'e nasıl geçtiği

• Microsoft Office, uzun süre şirket içi kaynak yönetim sistemi Source Depot'yu kullandıktan sonra, geliştirici deneyimi ve teknik yenilik için Git'e büyük ölçekli bir geçiş gerçekleştirdi
• Source Depot, merkezi yapı, yavaş dallanma, elverişsiz iş akışları nedeniyle üretkenlikte sınırlara sahipti; Git'e geçiş ise yüzlerce mühendisin ve yıllara yayılan çalışmanın sonucu oldu
• Geçiş sürecinde VFS for Git gibi yeni teknolojilerin geliştirilmesi, mevcut derleme/test altyapısının taşınması, sistemlerin paralel işletilmesi gibi büyük teknik ve organizasyonel zorluklar aşıldı
• Başarılı bir geçiş için "champion" odaklı iletişim yapısı, cesur şeffaflık, pratik eğitim ve anında geri alma stratejisi gibi işbirlikçi ve insan odaklı bir yaklaşım vurgulandı
• Geçiş sonrasında onboarding süresinin kısalması, Git tercih oranının artması (%89) ve üretkenlik artışı gibi olumlu sonuçlar elde edildi; aynı zamanda büyük ölçekli teknik değişimlere dair önemli dersler bırakıldı

---

Source Depot'tan Git'e: Microsoft Office'in büyük ölçekli geçiş deneyimi

Geliştirici üretkenliğini en üst düzeye çıkarma yönünde yeni bir meydan okuma

• Geliştirici üretkenliğini artırma çalışmaları 'Multiplier work' niteliğindedir ve organizasyon büyüdükçe değeri daha da artar
• Microsoft Office'in Source Depot'tan Git'e geçişi bu durumun temsilî örneklerinden biriydi
• Bu çalışma, basit bir araç değişiminden ibaret değildi; yüzlerce mühendisi, karmaşık sistemleri ve uzun bir zaman dilimini kapsayan büyük bir projeydi

Source Depot: o dönemin kaynak yönetimi hikâyesi

• 2000'lerin başında Microsoft, Perforce teknolojisi tabanlı kendi sürüm yönetim sistemi Source Depot'yu işletiyordu
• Source Depot; yavaş dallanma, merkezi yapı, uzun kod checkout süreleri ve elverişsiz birleştirme yöntemi (Reverse/Forward Integrate) nedeniyle iş verimliliğinde sınırlamalar yaratıyordu
• Tüm geliştirme altyapısına (derleme, sürüm, iş akışı) sıkı biçimde bağlı olduğundan, basitçe değiştirilebilecek bir yapı değildi
• Microsoft Office'in Git dönüşümü yıllar ve yüzlerce mühendisin emeğini gerektirdi

OneNote ile başlayan geçiş

• Office mühendislik organizasyonunda Source Depot'nun bakım/yama maliyeti ve “rekabetçi teknoloji” ihtiyacı nedeniyle büyük çaplı Git geçişi kararı alındı
• Office ürün ailesinde sürüm döngüleri (birkaç ayda bir, altı aylık, aylık, insider) farklı olduğu için uzun süreli Source Depot-Git paralel işletimi gerekiyordu
• Office sürüm yönetiminde tutarlılık, derleme doğrulaması ve eski test altyapısının taşınması zorunlu başlıklar olarak öne çıktı

Office'in ölçeği ve iletişim stratejisi

• Office, o dönemde 4.000 mühendisin birlikte çalıştığı devasa bir organizasyondu
• Her ekip için bir 'Developer Satisfaction Champion' belirlendi; ekipleri birbirine bağlayan hub-spoke modeli ile akıcı geri bildirim ve iletişim yapısı kuruldu
• Yazar, OneNote'un champion'ı olarak büyük ölçekli geçiş sahasında kilit bir rol üstlendi

VFS for Git: dev kod tabanının sınırlarını aşmak

• Tek bir git clone işleminin 200GB'den fazla gerektirecek kadar büyük bir kod tabanı söz konusuydu; bu sorun GitHub ile birlikte geliştirilen Virtual File System for Git (VFS for Git) ile çözüldü
• VFS for Git, yalnızca gerçekten kullanılan dosyaları getirerek temel Git'in sınırlarını aştı
• Microsoft Windows ile iş birliği içinde, sektörün en büyük sürüm yönetim sistemlerinden birinin sınırlarını aşan bir deneyim yaşandı

Geçişte aşamalı yaklaşım

1. aşama: Paralel evren (Parallel Universe)

• Source Depot ile Git'i gerçek zamanlı senkronize eden bir bridge servisi kuruldu; iki sistem arasındaki tutarsızlıklar ve model farkları (dal yapısı, changelist vb.) tekrar tekrar iyileştirildi
• Office ana/özel dalları-senkronizasyon-derleme süreci 7/24 otomatik bir sistemle işletildi
• Üç yeniden denemenin ardından kararlı çalışan paralel sistem hayata geçirildi

2. aşama: Eşdeğerlik doğrulaması

• Tüm test suite'leri iki sistemde tekrar tekrar çalıştırılarak derleme sonuçlarının tamamen aynı olduğu kanıtlandı
• Satır sonu biçimi, büyük/küçük harf, test sonuç biçimi gibi ince farklar aylar boyunca debug edilip çözüldü
• 'Green across the board' (her iki sistemde de tüm testler geçti) sonucuyla, gerçek geçiş aşamasına hazır olunduğu doğrulandı

İnsan odaklı yaklaşım

Çok kanallı, tekrar eden iletişim

• 4.000'den fazla mühendis ve onlarca ekibin takvimini hizalamak için, ekip champion'ları üzerinden yoğun bir iletişim sistemi kuruldu
• Önemli duyurular en az 3 kez (e-posta, Teams, wiki, toplantılar vb.) tekrar edilerek karışıklık en aza indirildi
• Sorun çıktığında, anında ve şeffaf bilgi paylaşımı ile güven sağlandı

Git'e geçiş eğitimi ve uyum

• 10 yıl boyunca Source Depot'ya alışmış mühendisler için uygulamalı eğitim ortamı ve geçiş komutları rehberi gibi kademeli bir öğrenme sistemi hazırlandı
• Pratik odaklı video kütüphanesi gibi kaynaklarla gerçek senaryolara dayalı öğrenme sunuldu
• Bu yaklaşım yalnızca kaygıyı azaltmak ve yetkinliği artırmakla kalmadı, mevcut iş akışına uyumu da destekledi

Geri alma stratejisi ve güvenlik önlemleri

• Gerçek geçiş anında Director'a bir 'red button' verildi; ciddi bir sorun halinde her an anında rollback yapılabiliyordu
• Source Depot'taki bazı geçmiş kayıtlar uzun süre korundu ve mevcut geliştirme geçmişi güvenli biçimde muhafaza edildi

Sonuçlar ve başlıca kazanımlar

• Geçiş sonrasında onboarding süresi %50 kısaldı, Git tercih oranının %89 olduğu görüldü, derleme performansı iyileşti; kod inceleme verimliliği ve ekipler arası iş birliği arttı; bunların tümü üretkenlik artışına dönüştü
• Mühendisler, sektörde aktarılabilir beceriler edinmeyi olumlu değerlendirdi
• Yeni çalışanların doğrudan katkı vermesi de daha kolay hale geldi

Büyük ölçekli geçişlerden çıkarılan temel dersler

• Yalnızca teknik unsurlara değil, insan odaklı iletişime de beklenenden çok daha fazla yatırım yapmak başarı için kritiktir
• Paralel sistem kurmak, tam eşdeğerliği kanıtlamak, en baştan sağlam bir rollback tasarlamak ve kilit kişileri (champion'lar) öne çıkarmak önemlidir
• Memnuniyet gibi nitel göstergelerin de birlikte ölçülmesi şarttır; değişim sürecinde organizasyonel istikrar ve psikolojik güvenlik duygusu kritik rol oynar
• Büyük ölçekli değişimin özü, organizasyon genelinde esnek ve sistematik değişim yönetimidir

Sonuç ve gelecekteki uygulamalar

• Office'in Git geçişi, yıllar süren hazırlık ve aylar süren icra ile gerçekleştirilen tarihî bir projeydi
• Sonuçta, binlerce kişinin iş bağlantılarını koruyarak organizasyonel değişimi başarıyla yürüten bir örnek olarak kaldı
• Cloud geçişi, monolitik mimarinin parçalanması, framework yükseltmeleri gibi diğer büyük dönüşümlerde de paralel doğrulama, tekrar eden iletişim ve hızlı rollback tasarımı aynı şekilde uygulanabilir
• Teknik ayrıntılar (derleme altyapısı, offline/sözleşme meseleleri vb.) ayrıca ele alınmamış olsa da, en önemli ders büyük ölçekli teknik değişimlerde stratejik ve organizasyonel yaklaşımın belirleyici olduğudur

[ndrgrd]

İkili dosyalarla çok çalışıyorsanız git uygun olmayabilir, ancak kod odaklı bir depo söz konusuysa git yeterli gibi görünüyor.

[rtyu1120]

MS içinde de büyük bir değişim olmuştur ama bunun sayesinde partial clone, sparse checkout gibi özellikler ve Scalar gibi araçların dışarıya da açılıp kullanılabilir hale gelmesi de bence güzel bir etki olmuş gibi haha

[GN⁺]

Hacker News görüşleri

• Bu eski hikâyeyi her seferinde taze bir anlatımla okumak her zaman keyifli geliyor. TFA, “Office deposunun tamamını içeri almak saatler sürdü” noktasına değiniyor ama aslında git tarafında bunun, VFS gibi yeni bir dosya sistemi olmadan neredeyse imkânsız olduğu gerçeğini büyük ölçüde atlıyor. Perforce'ta kullanıcılar yalnızca ihtiyaç duydukları kısımları checkout edebiliyordu; dolayısıyla çoğu Source Depot kullanıcısının da her seferinde Office uygulamasının tamamını değil, yalnızca gerekli parçaları aldığı tahmin ediliyor. VFS, git'te yalnızca gerekli nesnelerin indirilmesini sağlayarak bu farkı kapattı. Perforce/Source Depot o dönemde merkezi VCS olarak çok güçlü bir tercihti ama artık zamanın değiştiği hissediliyor.
  • Perforce için de VFS benzeri şekilde dosyaları yalnızca ihtiyaç anında getiren özel teknolojiler geliştiren şirketler olduğu belirtiliyor. Bu, özellikle oyun geliştirmede metin dosyalarıyla birlikte büyük ikili kaynak varlıklarını saklarken önemli. Bunun, Windows'a yerleşik uzak sürücü programının kullandığı teknolojiyle aynı kökten geldiği düşünülüyor. Kişisel olarak, şirketin tüm kaynak kodunun saklandığı ama tam geçmişin yerelde kopyalanmasını gerektirmeyen sunucu tabanlı bir VCS'yi hâlâ tercih ederdim. Öte yandan git, cihazlar arası tek seferlik iş birliği için yeterince kullanışlı; bu yüzden merkezi sunucu ve CI/CD hattı kurma ihtiyacı henüz hissedilmiyor. Git'teki stash, hunk bazında stage, etkileşimli rebase gibi çeşitli iş akışları da çok seviliyor.
  • Bizim şirket hâlâ Perforce kullanıyor ve artık kimsenin Perforce'u sevmediğini söylemek üzücü. Yeni başlayanlara “biz git kullanmıyoruz” dendiği anda gözlerindeki ışığın söndüğü bizzat görülüyor.
  • VFS, Perforce'un tam bir alternatifi değil. Nitekim AAA oyun şirketlerinin çoğu hâlâ Perforce kullanıyor. Varlık dosyalarına kilit (lock) koyarak iki kişinin aynı anda değişiklik yapıp birleştirilemez bir durum yaratmasını önlemek gerekiyor; ayrıca bir sanatçının emeğini çöpe atacak zaman kaybını azaltmak için bu şart.
  • Git'in neden hâlâ depo ağacının belirli bölümlerini seçmeli olarak checkout etmeyi desteklemediği açıkçası anlaşılmıyor. Nesne dosyaları gibi şeyleri anlayan bir ara servis eklenirse bunun kolayca genişletilebileceği düşünülüyor.
• 2016'daki Microsoft stajında, Source Depot'u destekleyen otomatik bir kod gözden geçirme aracı yaparken, Source Depot'un ne olduğunu bile bilmeden bu özelliğe neredeyse bir hafta harcamıştım (https://austinhenley.com/blog/featurestheywanted.html). O zaman da hâlâ birçok geliştirici Source Depot kullanıyordu. Şimdi hepsi git'e geçmiş mi merak ediliyor.
  • CodeFlow her gün özleniyor. Gerçekten harika bir araçtı.
  • Hâlâ Source Depot'un yoğun şekilde kullanıldığı çok alan olduğu söyleniyor. Source Depot komutları ve ortam ayarları insanı hep diken üstünde hissettiriyor.
  • Günlük işlerin çoğu artık git'te yürütülüyor.
• 90'larda bizzat vss (Visual SourceSafe) kullanmış biri olarak, bu yazıda ondan hiç bahsedilmemiş olması şaşırtıcı. Visual SourceSafe, Microsoft'un kendi yaptığı bir kaynak sürüm kontrol protokolüydü; Source Depot ise Perforce'tan lisanslanarak kullanılmış olması bakımından farklıydı.
  • VSS (Visual SourceSafe), Raleigh merkezli One Tree Software'in satın alınmasıyla edinilen bir üründü ve ürün adı “SourceSafe”ten “Visual SourceSafe”e çevrilip Visual C, Visual Basic vb. ile paket olarak sunuldu. Ondan önce “Microsoft Delta” adlı bir sürüm kontrol ürünü satılıyordu; pahalıydı, kalitesi düşüktü ve NT'de hiç desteklenmiyordu. One Tree satın alımıyla gelen isimlerden biri Brian Harry'ydi; kendisi Team Foundation Version Control'ü (TFS) yönetti. Depo olarak SQL Server kullanılması, VSS'ye kıyasla yönetilebilirlik ve güvenilirliği ciddi biçimde artırdı. Brian Harry'nin şimdi emekli olduğu ve blogunu artık güncellemediği anlaşılıyor. O dönemde VSS kullanırken akılda kalan şeylerden biri, ağ dosya kilitlemesini SMB ile yapması yüzünden sık ağ hatalarına açık olması ve deponun sık sık bozulmasıydı. Bu yüzden her gece yarısı onarım yapan bir toplu iş çalıştırılırdı; sabah kullanıma hazır olması gerekiyordu.
  • 90'larda VSS kullanmış biri olarak, ekip halinde çalışırken bunun tam bir kâbus olduğunu söyleyebilirim; bildiğim kadarıyla Microsoft da içeride bunu pek kullanmıyordu.
  • 90'larda tek başıma geliştirirken VSS kullanıyordum ve o dönem için bambaşka bir dünyaydı. Lisansüstü eğitimde başka VCS'lerle (RCS, CVS vb.) tanıştım. 2004'te Microsoft'a katıldığımda birisi VSS'nin güvensiz ve bozulmaya yatkın olduğunu anlatmıştı. Bunun ne kadar doğru olduğunu bilmiyorum ama şirkette VSS zaten bir seçenek bile değildi.
• Microsoft'un XNS'ten TCP/IP'ye geçişinde ekip üyesiydim. Bu, beklenenden pek de karmaşık değildi ama benzer dersler çıkardı. MSMAIL'den Exchange'e geçiş ise gerçekten zordu.
  • Bir zamanlar üzerinde “Exchange: The Most Feared and Loathed Team in Microsoft” yazan bir plakalık çerçevesi görmüştüm; bunun o deneyimlerden kaynaklanıp kaynaklanmadığını merak ediyorum. 20 yıl önceydi, tam ifadeyi hatırlamıyorum.
• “Authenticity mattered more than production value” sözü gerçekten çok yerinde. Source Depot'tan Git'e geçişe ancak işten ayrılmama yakın bir dönemde (2015) başlamış küçük bir ürün hattında çalışmış eski bir Microsoft çalışanı olarak, bunun ne kadar büyük emek gerektirdiğini tamamen anlayabiliyorum. Gerçekten etkileyici bir başarı.
  • Ben de bütün bunları gerçekten yaşamış olduğuma hâlâ inanamıyorum. Teşekkürler.
• 2000'lerin başındaki Microsoft'un durumuna bakınca, Windows aşırı karmaşık hâle gelmişti ve milyonlarca satır kod için sürüm kontrolü gerekiyordu; ama git henüz ortada yoktu, SVN ise daha yeni yükseliyordu. Microsoft'un 1998'de geliştirilmeye başlanıp 2000'de yayımlanan BitKeeper gibi ticari ürünleri ciddi biçimde değerlendirip değerlendirmediği merak ediliyor. Muhtemelen o dönemde Perforce gibi merkezi sistemler baskındı; BitKeeper gibi dağıtık çözümler ise ya fazla yabancı geliyordu ya da yeterince kanıtlanmış değildi.
  • O dönemde VSS (Visual SourceSafe) vardı, sonrasında da TFVC geldi.
• Benim gibi acemi bir mühendise Source Depot'un gizemlerini anlatan geliştirme liderlerine teşekkür borçluyum. Source Depot'un yapısını gerçekten anlayınca insanın gözü açılıyor. Ben yalnızca WinCE ve IE'ye bağımlı olduğum için clone işlemi sadece 20 dakika sürüyordu; günler almamış olması büyük şanstı. Yardım edenlerin isimlerini unutmuş olsam da, yeni başlayanların işe kolay adapte olmasına yardım etme tavrını kendi ekibimde sürdürmeye çalışıyorum.
• Çoğu kişi git'e geçişi teknik bir zafer olarak hatırlıyor ama asıl devrim, geliştiricilerin kendi iş akışlarını doğrudan kontrol edebilmesi oldu. Artık ne senkronizasyon penceresinin açılmasını beklemek gerekiyor ne de branch erişimi için ekip liderine ricada bulunmak. Herkes artık hızla çalışabiliyor ve yine de birbirinin yoluna çıkmıyor. Bu değişimin, verimlilik panolarından çok ekip havasını iyileştirdiği hissi çok güçlü. Git sadece bir araç değildi; geliştirme döngüsüne duyulan güveni de değiştirdi.
• Microsoft'un içeride Visual SourceSafe'ten tam olarak ne zaman çıktığı merak ediliyor. Bunu daha erken sonlandırıp en azından dışarıda kullanılmaya devam etmesini önlemeleri gerekirdi diye düşünülüyor.
  • Çoğu ekibin VSS'yi fiilen kullanmadığı düşünülüyor. Microsoft'ta çalışırken bizim ekip Source Depot kullanıyordu. O dönemde TFS de denenmiş ama pek sevilmemişti; hatta Source Depot kullanınca insan TFS'yi özler hâle geliyordu.
  • Microsoft'un VSS'yi ana amaçlarla içeride gerçekten kullanıp kullanmadığı şüpheli. Eğer gerçekten kullanmış olsalardı, muhtemelen ürünü bu kadar dağınık bir hâlde yayımlamazlardı. TFS ise hem içeride hem dışarıda anlaması zor bir deneyimdi ve pek iyi değildi.
  • Bunun muhtemelen 2000 civarı olduğu söyleniyor. Bilinen tek proje .NET'ti ve o bile zaten Source Depot'a geçmişti.
  • Microsoft SourceSafe diye bir şey olduğundan bile haberi olmayanlar var.
• OneNote shallow clone'unun 200GB olduğu iddiası pek anlaşılmıyor.
  • Aslında OneNote değil, Office'in tamamının shallow clone'undan söz ediliyordu.
  • İçinde video veya büyük ikili dosyalar olduğu tahmin ediliyor.