Bagaimana Microsoft Office Bermigrasi dari Source Depot ke Git

• Microsoft Office telah lama menggunakan Source Depot, sistem manajemen source code internal, lalu melakukan migrasi besar-besaran ke Git demi pengalaman pengembang dan inovasi teknis
• Source Depot memiliki keterbatasan produktivitas karena tersentralisasi, branching lambat, dan alur kerja yang tidak praktis, sehingga perpindahan ke Git membutuhkan ratusan engineer dan pekerjaan selama beberapa tahun
• Dalam proses migrasi, mereka mengatasi tantangan teknis dan organisasi skala besar seperti pengembangan teknologi baru seperti VFS for Git, porting infrastruktur build/test lama, dan pengoperasian sistem paralel
• Untuk keberhasilan migrasi, mereka menekankan pendekatan kolaboratif dan berpusat pada manusia seperti sistem komunikasi berbasis "champion", transparansi yang berani, pelatihan praktis, dan strategi rollback instan
• Setelah migrasi, muncul hasil positif seperti waktu onboarding yang menurun, peningkatan preferensi terhadap Git (89%), dan produktivitas yang lebih baik, sekaligus meninggalkan pelajaran penting tentang perubahan teknis berskala besar

---

Dari Source Depot ke Git: Pengalaman migrasi skala besar Microsoft Office

Tantangan baru: memaksimalkan produktivitas pengembang

• Upaya meningkatkan produktivitas pengembang adalah 'Multiplier work', dan nilainya makin besar di organisasi berskala besar
• Proyek migrasi Microsoft Office dari Source Depot ke Git menjadi contoh pengalaman yang representatif
• Pekerjaan ini bukan sekadar pergantian alat, melainkan proyek besar yang melibatkan ratusan engineer, sistem yang kompleks, dan waktu yang panjang

Source Depot: kisah pengelolaan source code pada masa itu

• Pada awal 2000-an, Microsoft mengoperasikan Source Depot, sistem version control internal berbasis teknologi Perforce
• Source Depot memiliki keterbatasan efisiensi kerja karena branching yang lambat, sentralisasi, waktu checkout kode yang panjang, serta metode merge yang tidak nyaman (Reverse/Forward Integrate)
• Karena sangat terikat dengan seluruh infrastruktur pengembangan (build, release, workflow), sistem ini tidak bisa begitu saja diganti
• Peralihan Microsoft Office ke Git membutuhkan waktu bertahun-tahun dan upaya ratusan engineer

Dimulai dari OneNote: awal migrasi

• Di organisasi engineering Office, biaya pemeliharaan dan patch Source Depot serta kebutuhan akan “teknologi yang kompetitif” mendorong keputusan migrasi besar-besaran ke Git
• Karena lini produk Office memiliki jadwal pengembangan yang berbeda menurut siklus rilisnya (beberapa bulan, semesteran, bulanan, Insider), diperlukan operasi paralel Source Depot-Git dalam jangka panjang
• Konsistensi version control Office, verifikasi build, dan porting infrastruktur test legacy pun muncul sebagai tugas penting

Skala Office dan strategi komunikasi

• Saat itu, Office adalah organisasi raksasa tempat 4.000 engineer berkolaborasi
• Setiap tim menunjuk 'Developer Satisfaction Champion', lalu membangun struktur feedback dan komunikasi yang lancar melalui model hub-spoke yang menghubungkan tiap tim
• Penulis berperan sebagai champion untuk OneNote dan memegang peran kunci di lapangan dalam migrasi berskala besar ini

VFS for Git: menembus batas codebase raksasa

• Karena satu kali git clone saja membutuhkan lebih dari 200GB, masalah ini diatasi dengan Virtual File System for Git (VFS for Git) yang dikembangkan bersama GitHub
• VFS for Git mengatasi keterbatasan Git standar dengan cara hanya mengambil file yang benar-benar digunakan
• Bersama Microsoft Windows, ini menjadi pengalaman menembus batas sistem version control berskala terbesar di industri

Pendekatan migrasi bertahap

Tahap 1: Parallel Universe

• Mereka membangun layanan bridge yang menyinkronkan Source Depot dan Git secara real-time, lalu berulang kali memperbaiki masalah ketidaksesuaian dan perbedaan model kedua sistem (struktur branch, changelist, dan lain-lain)
• Proses branch utama/private Office-sinkronisasi-build dioperasikan sebagai sistem otomatis 24/7
• Setelah tiga kali percobaan ulang, sistem paralel yang stabil akhirnya berhasil diwujudkan

Tahap 2: verifikasi ekuivalensi

• Seluruh test suite dijalankan berulang di kedua sistem untuk membuktikan bahwa hasil build benar-benar identik
• Perbedaan halus seperti format line ending, huruf besar-kecil, dan format hasil test di-debug serta diselesaikan selama berbulan-bulan
• Dengan capaian 'Green across the board' (test lulus di kedua sistem), mereka siap masuk ke tahap transisi nyata

Pendekatan yang berpusat pada manusia

Komunikasi multi-kanal dan berulang

• Untuk menyelaraskan jadwal 4.000+ engineer dan puluhan tim, dibangun sistem komunikasi intensif bersama champion di tiap tim
• Pengumuman penting disampaikan setidaknya 3 kali (email, Teams, wiki, meeting, dan sebagainya) untuk meminimalkan kebingungan
• Saat masalah muncul, keterbukaan informasi yang langsung dan transparan digunakan untuk membangun kepercayaan

Pelatihan adopsi Git dan proses adaptasi

• Untuk engineer yang telah terbiasa dengan Source Depot selama 10 tahun, disiapkan lingkungan pelatihan berbasis praktik serta panduan perintah transisi sebagai sistem pembelajaran bertahap
• Melalui pustaka video yang berfokus pada praktik nyata, mereka menyediakan pembelajaran berbasis skenario riil
• Pendekatan ini tidak hanya mengurangi kecemasan dan memperkuat kemampuan, tetapi juga membantu adaptasi terhadap workflow yang sudah ada

Strategi rollback dan pengaman

• Saat transisi nyata dilakukan, Director diberi 'red button' sehingga rollback bisa dilakukan kapan saja bila terjadi masalah serius
• Sebagian riwayat lama di Source Depot tetap dipertahankan dalam jangka panjang agar histori pengembangan yang ada tetap aman

Hasil dan pencapaian utama

• Setelah migrasi, terlihat penurunan waktu onboarding sebesar 50%, preferensi terhadap Git sebesar 89%, peningkatan performa build, efisiensi code review, dan kolaborasi yang lebih baik sebagai dampak peningkatan produktivitas
• Para engineer juga menilai positif karena mereka memperoleh keterampilan yang dapat ditransfer di industri
• Kemampuan personel baru untuk langsung berkontribusi juga meningkat

Pelajaran inti dari migrasi skala besar

• Keberhasilan tidak hanya bergantung pada faktor teknis; perlu investasi komunikasi yang berpusat pada manusia jauh lebih besar dari perkiraan
• Penekanan diberikan pada pembangunan sistem paralel, pembuktian ekuivalensi yang sempurna, desain rollback yang tegas sejak awal, dan peran personel kunci (champion)
• Pengukuran paralel atas indikator kualitatif seperti tingkat kepuasan juga mutlak diperlukan, dan dalam proses perubahan, stabilitas organisasi serta rasa aman psikologis sangat penting
• Hakikat perubahan besar adalah manajemen perubahan yang luwes dan sistematis di seluruh organisasi

Penutup dan penerapan ke depan

• Migrasi Git di Office adalah proyek bersejarah yang terwujud melalui persiapan selama bertahun-tahun dan eksekusi selama berbulan-bulan
• Pada akhirnya, ini menjadi contoh keberhasilan mendorong perubahan organisasi sambil menjamin keterhubungan kerja ribuan orang
• Dalam perubahan besar lain seperti migrasi cloud, pemecahan arsitektur monolitik, atau upgrade framework, verifikasi paralel, komunikasi berulang, dan desain rollback cepat dapat diterapkan dengan cara yang sama
• Detail teknis seperti infrastruktur build serta isu offline/kontrak tidak dibahas lebih lanjut, tetapi pelajaran terpenting tetaplah pendekatan strategis dan organisasional terhadap perubahan teknis berskala besar

[ndrgrd]

Kalau banyak menangani file biner, git mungkin kurang cocok, tetapi untuk repositori yang berfokus pada kode, sepertinya git sudah cukup memadai.

[rtyu1120]

Mungkin ini juga perubahan besar di internal MS, tetapi efek positifnya adalah fitur seperti partial clone, sparse checkout, dan alat seperti Scalar juga jadi dipublikasikan ke luar sehingga bisa digunakan oleh publik haha

[GN⁺]

Komentar Hacker News

• Selalu menyenangkan membaca tulisan yang mengangkat kisah lama seperti ini dengan sudut pandang baru. TFA menyebut bahwa “butuh beberapa jam untuk mengambil seluruh repositori Office”, tetapi praktis mengabaikan fakta bahwa di git hal seperti ini hampir mustahil tanpa sistem berkas baru seperti VFS. Di Perforce, pengguna bisa checkout hanya bagian yang mereka butuhkan, jadi kemungkinan besar sebagian besar pengguna Source Depot juga tidak mengambil seluruh aplikasi Office setiap saat, melainkan hanya bagian yang diperlukan. VFS mempersempit kesenjangan ini dengan membuat git hanya mengunduh objek yang dibutuhkan. Perforce/Source Depot adalah VCS terpusat yang merupakan pilihan sangat kuat pada masanya, tetapi sekarang rasanya zamannya sudah berubah.
  • Dijelaskan bahwa di Perforce juga ada perusahaan yang membuat teknologi sendiri mirip VFS, yang hanya mengambil file saat dibutuhkan. Ini sangat penting terutama dalam pengembangan game, ketika aset sumber biner berukuran besar disimpan bersama file teks. Rasanya teknologi ini berakar sama dengan teknologi yang dipakai program drive jarak jauh bawaan Windows. Secara pribadi, saya masih menginginkan VCS berbasis server yang menyimpan seluruh source code perusahaan tanpa perlu mereplikasi seluruh histori ke lokal. Namun git masih cukup layak untuk kolaborasi sesekali antarperangkat, jadi saya belum merasa perlu menyiapkan server terpusat dan pipeline CI/CD. Saya sangat menyukai berbagai workflow di git seperti stash, stage per hunk, dan interactive rebase.
  • Perusahaan kami masih memakai Perforce, dan sangat disayangkan sekarang hampir tidak ada yang menyukai Perforce. Saya benar-benar melihat cahaya di mata para pegawai baru padam saat diberi tahu, “kami tidak memakai git”.
  • VFS tidak sepenuhnya menggantikan Perforce. Ditekankan bahwa sebagian besar perusahaan game AAA masih menggunakan Perforce. Mereka perlu memasang lock pada file aset agar dua orang tidak mengeditnya bersamaan dan menimbulkan situasi yang tidak bisa di-merge, dan ini penting untuk mengurangi pemborosan waktu ketika hasil kerja seorang artis harus dibuang.
  • Jujur saya heran kenapa git sampai sekarang masih belum menyediakan kemampuan untuk secara selektif checkout hanya bagian tertentu dari pohon repositori. Rasanya ini bisa diperluas dengan mudah jika menambahkan layanan perantara yang memahami object file dan semacamnya.
• Saat magang di Microsoft pada 2016, saya pernah membuat code reviewer otomatis yang mendukung Source Depot. Saya bahkan tidak tahu apa itu Source Depot dan menghabiskan hampir seminggu untuk fitur ini (https://austinhenley.com/blog/featurestheywanted.html). Waktu itu pun masih banyak developer yang memakai Source Depot. Saya jadi penasaran apakah sekarang semuanya sudah pindah ke git.
  • Saya merindukan CodeFlow setiap hari. Itu benar-benar alat yang keren.
  • Masih banyak area yang tetap aktif menggunakan Source Depot. Command Source Depot dan konfigurasi lingkungannya selalu membuat saya tegang.
  • Sebagian besar pekerjaan sehari-hari saya sekarang ditangani di git.
• Sebagai orang yang benar-benar memakai vss(Visual SourceSafe) di era 90-an, saya terkejut cerita itu sama sekali tidak disebut dalam artikel ini. Visual SourceSafe adalah protokol manajemen versi source code buatan Microsoft sendiri, sedangkan Source Depot berbeda karena dilisensikan dari Perforce.
  • VSS(Visual SourceSafe) adalah produk yang didapat lewat akuisisi One Tree Software di Raleigh, lalu nama produknya diubah dari “SourceSafe” menjadi “Visual SourceSafe” dan dibundel bersama Visual C, Visual Basic, dan lain-lain. Sebelumnya Microsoft menjual produk manajemen versi bernama “Microsoft Delta”, tetapi mahal, berkualitas buruk, dan bahkan tidak didukung di NT. Salah satu orang yang ikut masuk lewat akuisisi One Tree adalah Brian Harry, dan dia kemudian memimpin Team Foundation Version Control(TFS). Dengan memakai SQL Server sebagai repositori, pengelolaan dan keandalannya jauh lebih baik daripada VSS. Sepertinya Brian Harry sekarang sudah pensiun dan blognya juga tidak diperbarui lagi. Salah satu hal yang saya ingat saat memakai VSS adalah file locking jaringan ditangani lewat SMB, sehingga sangat rentan terhadap error jaringan yang sering terjadi, dan repositori pun kerap rusak. Karena itu kami harus menjalankan batch job pemulihan setiap dini hari agar pulih otomatis pada malam hari, karena pagi harinya sistem harus bisa dipakai.
  • Dari pengalaman memakai VSS di era 90-an, saat dipakai bekerja dalam tim itu nyaris seperti mimpi buruk, dan setahu saya Microsoft sendiri juga hampir tidak memakainya secara internal.
  • Saya pernah memakai VSS saat mengembangkan sendirian di era 90-an, dan waktu itu rasanya seperti dunia baru. Saat kuliah pascasarjana saya juga mengenal VCS lain seperti RCS dan CVS. Ketika masuk Microsoft pada 2004, saya ingat seseorang menjelaskan bahwa VSS tidak aman dan mudah rusak. Saya tidak tahu apakah itu benar, tetapi bagaimanapun juga di perusahaan VSS bahkan bukan pilihan sama sekali.
• Saya adalah anggota tim saat Microsoft bermigrasi dari XNS ke TCP/IP. Pekerjaan itu ternyata tidak terlalu rumit, tetapi saya mendapat pelajaran yang mirip. Migrasi dari MSMAIL ke Exchange benar-benar sulit.
  • Saya pernah melihat bingkai pelat nomor bertuliskan “Exchange: The Most Feared and Loathed Team in Microsoft”, dan saya penasaran apakah itu karena pengalaman saat itu. Sudah 20 tahun lalu jadi saya tidak ingat persis kalimatnya.
• Kalimat “Authenticity mattered more than production value” benar-benar terasa mengena. Sebagai mantan karyawan Microsoft yang bekerja di lini produk kecil yang baru mulai beralih dari Source Depot ke Git tepat sebelum saya pergi pulang-pergi kerja (2015), saya sangat paham betapa besarnya usaha yang dibutuhkan untuk pekerjaan seperti ini. Ini pencapaian yang luar biasa.
  • Saya juga merasa sulit percaya bahwa saya pernah melalui semua proses itu. Terima kasih.
• Jika melihat situasi yang dihadapi Microsoft pada awal 2000-an, Windows menjadi sangat kompleks dan jutaan baris kode memerlukan version control, tetapi git belum ada dan SVN pun masih baru berkembang. Saya penasaran apakah Microsoft juga pernah serius mempertimbangkan produk komersial seperti BitKeeper, yang dikembangkan pada 1998 dan dirilis pada 2000. Dugaan saya, saat itu sistem terpusat seperti Perforce memang arus utama, sedangkan sistem terdistribusi seperti BitKeeper mungkin terasa asing atau belum punya cukup contoh keberhasilan yang terbukti.
  • Saat itu ada VSS(Visual SourceSafe), dan setelahnya ada TFVC.
• Saya berterima kasih kepada para development lead yang menjelaskan misteri Source Depot kepada engineer pemula seperti saya. Begitu saya benar-benar memahami struktur Source Depot, rasanya seperti mendapat pencerahan. Karena saya hanya bergantung pada WinCE dan IE, clone saya hanya butuh 20 menit, bukan berhari-hari, dan saya sangat bersyukur untuk itu. Saya sudah lupa nama orang-orang yang membantu saya, tetapi sikap mereka yang ingin membantu pegawai baru agar bisa mulai bekerja dengan mudah terus saya lanjutkan dan praktikkan di tim saya sekarang.
• Kebanyakan orang mengingat adopsi git sebagai kemenangan teknis, tetapi sebenarnya inovasi yang sesungguhnya adalah setiap developer akhirnya bisa mengendalikan workflow mereka sendiri. Tidak perlu lagi menunggu jendela sinkronisasi, dan tidak perlu lagi meminta lead untuk akses branch. Sekarang semua orang bisa melaju bebas tanpa saling bertabrakan. Saya sangat merasa perubahan ini berdampak jauh lebih besar pada membaiknya suasana kerja daripada dashboard produktivitas apa pun. Git bukan hanya mengubah alat, tetapi juga mengubah rasa percaya terhadap loop pengembangan itu sendiri.
• Saya penasaran kapan Microsoft secara internal benar-benar meninggalkan Visual SourceSafe. Menurut saya mereka seharusnya menghentikannya lebih cepat agar setidaknya tidak terus dipakai oleh pihak luar.
  • Saya rasa sebagian besar tim memang tidak benar-benar memakai VSS. Saat bekerja di Microsoft, tim kami menggunakan Source Depot. Saya juga pernah mencoba TFS dan tidak terlalu menyukainya. Meski begitu, setelah memakai Source Depot, malah TFS jadi terasa dirindukan.
  • Saya ragu VSS pernah dipakai Microsoft secara utama di internal. Jika memang benar dipakai secara internal, rasanya mereka tidak akan merilisnya dalam kondisi produk yang begitu rapuh. TFS juga pengalaman yang sulit dipahami, dan tidak terasa bagus baik di dalam maupun di luar perusahaan.
  • Mungkin sekitar tahun 2000. Satu-satunya proyek yang saya tahu memakainya adalah .NET, tetapi bahkan itu pun sudah berpindah ke Source Depot.
  • Reaksi bahwa saya bahkan tidak tahu Microsoft SourceSafe itu ada.
• Saya kurang paham dengan cerita bahwa shallow clone OneNote berukuran 200GB.
  • Penjelasannya, itu sebenarnya bukan OneNote, melainkan shallow clone seluruh Office.
  • Kemungkinan ada video atau biner besar di dalamnya.