Nggedhekake Skala Git ing OpenAI

Sajrone setaun pungkasan, ukuran lan kabutuhan monorepo kita mundhak kanthi cepet banget. Cetha yen kita kudu ndandani sistem kontrol kode sumber supaya bisa ngimbangi akehe pakaryan bebarengan sing bisa ditindakake nganggo Codex.

Kita mbangun Pando, backend anyar kanggo gudang kode Git, tanpa ngganggu pakaryan rekayasa utawa ngganti cara tim kita nggunakake Git. Saiki Pando nyengkuyung kabeh pangembangan ing monorepo OpenAI. Pando dirancang kanggo nggayuh rong ancas ambisius: kapisan, operasi nulis sing kapasitase bisa digedhekake sacara horisontal, dioptimalake kanggo push bebarengan menyang akeh cabang. Kapindho, nggedhekake kapasitas pangolahan maca nganti maksimal, supaya klien bisa ngundhuh data kanthi cukup cepet kanggo nggunakake kabeh bandwidth jaringan sing kasedhiya.

Kita nggayuh ancas kasebut kanthi tetep njaga kompatibilitas karo protokol lan klien Git, saengga insinyur lan agen kita bisa nggunakake Pando kanthi lancar ing alur kerja sing wis ana. Ing lingkungan produksi, Pando nyuda median latensi push nganti meh sapralima. Saiki Pando ngirim meh sak petabyte data Git saben dina.

Ing kene, kita bakal ngrembug alasan mbangun sistem kontrol kode sumber anyar lan sebab kita milih tetep njaga kompatibilitas karo Git. Kita bakal mbandhingake sistem kita karo pendekatan umum kanggo nggedhekake skala Git, lan nerangake kabisan khas Pando kanggo nyukupi kabutuhan skalabilitas OpenAI. Kita uga ngrembug langkah sabanjure lan cara kita terus nyumbang marang Git kanggo nyengkuyung pakaryan ing skala agen.

Codex wis ngowahi skala lan kacepetan pangembangan ing OpenAI, saengga insinyur bisa nindakake luwih akeh pakaryan kanthi paralel. Tegese, luwih akeh cabang lan push, luwih akeh merge, sarta luwih akeh fetch lan clone saka lingkungan pangembangan, tugas riset, lan CI.

Kabutuhan iki saya numpuk. Saiki siji insinyur bisa nyiapake sawetara owah-owahan kanggo CI bebarengan, lan saben push bisa micu sawetara tugas kanggo njupuk commit sing padha.

Wiwit watara pungkasan taun kepungkur, sistem sing nyengkuyung monorepo kita wiwit angel ngimbangi kabutuhan iki. Kita ngalami fetch lan push sing alon sarta merge sing gagal, kanthi keandalan sing kadhang mudhun nganti sangisore 90%. Apa kita wis tekan watese Git dhewe, utawa watese cara kita nglayani monorepo? Git tuwuh saka komunitas sing ijolan patch kanggo kernel liwat email. Sajrone luwih saka rong dasawarsa, pangembang wis nyelarasake pirantine karo Git nalika cara mbangun piranti lunak saya owah. Nalika kita wiwit nemoni alangan ing monorepo dhewe, penting tumrap kita supaya bisa terus mbangun adhedhasar asil pakaryan kasebut.

Kita weruh cara kanggo njaga alur kerja sing wis lumrah, sinambi mbangun maneh backend supaya bisa nangani push menyang cabang beda kanthi paralel lan nyedhiyakake riwayat sing padha kanggo akeh pamaca bebarengan. Nggunakake Git minangka dhasar alur kerja kontrol kode sumber ateges paningkatan klien uga bisa migunani ing njaba OpenAI. Kita kepengin nyumbangake paningkatan kasebut saka salinan Git kita⁠(mbukak ing jendhela anyar) menyang proyek induk, supaya bisa dienggo bareng komunitas sing luwih jembar.

Nggenjot skala sistem kontrol kode sumber nduweni rong aspek utama: akeh panulis nindakake push menyang cabang beda, lan akeh pamaca njupuk riwayat sing padha. Pando ngoptimalake loro-lorone.

Kapisan, Pando ngoordinasi nganyari saben cabang kanthi mandiri. Nganyari cabang sing ora gegandhengan bisa lumaku kanthi paralel, lan pamaca sing njupuk cabang entuk riwayat sing dibutuhake kanggo revisi kasebut. Kompromine, pamaca sing ndeleng sawetara cabang bisa ndeleng kahanan cabang-cabang kasebut saka wektu sing beda.

Kapindho, Pando nggunakake maneh packfile (format Git kanggo ngompres pirang-pirang objek bebarengan) ing maneka fetch, tinimbang nggawe packfile dhewe kanggo saben klien. Klien bisa uga ngundhuh sawetara objek sing wis diduweni, nanging server bisa ngirim byte sing padha menyang akeh klien kanthi komputasi sithik.

Pilihan iki ngidini kita nggedhekake kapasitas nulis ing antarane cabang lan nglayani operasi maca saka cache. Kanggo mangerteni carane loro-lorone bisa nyambut gawe bebarengan, ayo miwiti saka cara Git nyimpen lan ngirim riwayat.

Git kudu bisa njaga rong bagean gudang kode supaya tetep sinkron: objek lan referensi.

Gudang kode Git nyathet potret kahanan file lan riwayat sing ngubungake minangka graf objek. Objek bisa awujud blob, tree, commit, utawa tag. Blob nyimpen isi siji file, dene tree nggandhengake jeneng karo blob utawa tree liyane kanggo mbentuk struktur direktori. Commit nuding menyang tree oyod lan nol utawa luwih commit induk, sing mbentuk riwayat gudang kodemu.

Objek diidentifikasi nganggo hash saka jinis lan isine. Objek uga ora bisa diowahi: nyathet file sing wis diowahi bakal nggawe blob anyar, dene file lan direktori sing ora owah bisa nggunakake maneh objek sing wis ana.

Cabang lan tag yaiku referensi, utawa “ref”, sing nuding menyang commit. Nindakake commit ing cabang bakal nggawe commit anyar lan nganyari ref cabang supaya nuding menyang commit kasebut.

Git nyimpen objek ing kahanan “kapisah” utawa “dikemas”. Objek kapisah disimpen ing file dhewe-dhewe sing diidentifikasi nganggo ID objeke. Objek sing dikemas disimpen bebarengan ing packfile, saengga objek sing padha bisa disimpen minangka delta marang siji lan sijine.

Ing Git, objek bisa digayuh saka commit yen Git bisa nemokake kanthi ngetutake pranala saka commit kasebut liwat induk, tree, lan blob. Sajrone fetch, klien ngandhani server commit endi sing dikarepake lan endi sing wis diduweni. Server nggoleki objek sing bisa digayuh saka commit sing dikarepake, ora nglebokake objek sing dingerteni wis diduweni klien, banjur ngirim sisane minangka packfile kanthi format sing padha karo sing digunakake Git ing disk. Clone lengkap diwiwiti tanpa objek apa wae, mula mbutuhake kabeh objek sing bisa digayuh saka riwayat sing dikloning.

Push ngirim objek menyang arah kosok baline kanthi njaluk server nganyari siji utawa luwih ref. Klien nggunakake kumpulan ref sing diwartakake server supaya ora ngirim objek sing wis diduweni server. Mula, pack sing dikirim bisa gumantung marang objek sing wis ana: mung nampa pack ora cukup kanggo mbangun maneh riwayat anyar.

Ngreplikasi gudang kode Git ateges njaga objek lan referensi supaya kasedhiya ing pirang-pirang server. Sadurunge replika bisa nyedhiyakake nilai anyar saka referensi, replika kudu bisa nyedhiyakake objek sing bisa digayuh saka nilai kasebut. Layanan uga kudu ngoordinasi nganyari referensi sing padha rebutan, yaiku push sing nyoba mindhah cabang sing padha saka pucuk lawas sing padha menyang commit anyar sing beda. Sistem sing meksa siji urutan kanggo kabeh operasi nulis ing gudang kode bisa ndadekake push menyang cabang sing ora gegandhengan kudu padha ngenteni.

Nalika ngrancang Pando, kita ngevaluasi pendekatan konvensional kanggo nggedhekake skala kontrol kode sumber nganggo Git: siji ngoordinasi nganyari ref ing antarane replika gudang kode nganggo commit telung fase (3PC, protokol kanggo ngoordinasi commit ing pirang-pirang simpul), lan sijine ngurutake owah-owahan liwat write-ahead log bebarengan (WAL, cathetan owah-owahan sing ditulis sadurunge ditrapake) ing panyimpenan blob.

Ing rancangan commit telung fase sing kita modelake, layanan Git nyimpen salinan lengkap gudang kode ing sawetara replika. Nalika server apa wae nampa push, packfile sing mlebu disalin lan dikirim menyang kabeh replika kanthi paralel. Kanggo nerbitake push, mayoritas replika kudu nampa owah-owahan ref. Server sing ngatur iki diarani koordinator, lan proses iki mbutuhake sawetara puteran komunikasi antarane koordinator lan saben replika liyane.

Kanggo nampa owah-owahan referensi, saben replika ngunci salinan ref lan mriksa yen ref kasebut isih nuding menyang commit sing dikarepake klien. Koordinator banjur ngirim pesen pra-commit marang replika sing nampa. Sawise mayoritas ngakoni pesen pra-commit, koordinator mrentah replika kasebut supaya nindakake nganyari. Replika apa wae sing wis paling anyar banjur bisa mewartakake pucuk cabang anyar saka salinan lokal gudang kode.

Nyimpen replika lengkap ngidini operasi maca dilayani sacara lokal, lan njamin klien entuk gambaran kabeh referensi sing konsisten, replika endi wae sing dipilih. Akibate, referensi dianyari siji mbaka siji, lan saben push mbutuhake sawetara komunikasi bolak-balik kanggo ngoordinasi nganyari ref ing antarane replika.

Amarga kudu ngenteni kuorum, kinerja disk replika lan latensi komunikasi dadi faktor sing mengaruhi alur push. Nalika volume nulis mundhak, replika kudu bisa ngimbangi pack sing mlebu sarta lalu lintas maca.

Ing rancangan adhedhasar WAL sing kita modelake, layanan Git nggunakake manifest bebarengan ing panyimpenan blob kanggo ngurutake owah-owahan ing saindhenging gudang kode. Nalika server nampa push, server ngunggah packfile sing mlebu menyang panyimpenan blob lan nyiapake owah-owahan ref ing salinan lokal gudang kode. Kanggo nerbitake push, server nambah entri menyang manifest bebarengan ing panyimpenan blob, sing nyathet owah-owahan ref lan nuding menyang packfile. Server Git banjur nganyari manifest nganggo operasi compare-and-swap. Operasi iki ngganti manifest kanthi atomik, utawa nolak owah-owahan kasebut. Yen panulis liyane wis nganyari manifest ing sela wektu kasebut, server maca entri sing ditambahake, mriksa yen owah-owahan refe isih sah, banjur nyoba maneh nganggo packfile sing wis diunggah.

Panulis bisa ngunggah packfile kanthi paralel, nanging sanajan push menyang cabang sing ora gegandhengan, kabeh isih kudu nganyari manifest sing padha. Wektu bolak-balik kanggo compare-and-swap sing kasil mbatesi sepira kerepe gudang kode bisa nerbitake manifest anyar. Panyimpenan blob kanthi latensi cendhek ndadekake langkah iki cepet. Pangolahan kanthi kelompok ngidini siji manifest nganyari sawetara ref bebarengan, nanging kudu ngantrikake owah-owahan lan nambah latensi.

Panyimpenan blob bisa nampa packfile kanthi paralel, nanging operasi nganyari manifest bebarengan isih padha rebutan. Mung nambah kapasitas panyimpenan blob ora ngrampungake alangan kasebut. Saben replika isih kudu maca lan ngindeks pack saka panyimpenan blob sadurunge bisa nglayani sacara lokal. Yen operasi nulis sing mlebu luwih cepet tinimbang pakaryan kasebut, replika bakal ketinggalan lan klien kudu ngenteni luwih suwe kanggo njupuk commit sing lagi wae dikirim liwat push.

Saka kene kita tekan Pando. Pando minangka arsitektur anyar kanggo nglayani gudang kode Git, kanthi ancas nggedhekake kapasitas supaya bisa nampung akeh klien sing nindakake push bebarengan. Mangkene cara kerjane:

Sadurunge ngembangake Pando, kita duwe pangira yen kabutuhan kita bisa dicukupi tanpa ngorbanake Git. Nanging, kita pancen kudu nglonggarake sawetara perkara sing dianggep minangka syarat dening umume sistem Git:

• Konsistensi ing saindhenging gudang kode: Nyedhiyakake potret kahanan kabeh ref sing konsisten ing siji wektu mbutuhake koordinasi ing saindhenging gudang kode. Ing sistem sing ngurutake kabeh nganyari ref bebarengan, push menyang cabang sing ora gegandhengan padha rebutan ing siji titik koordinasi.

• Packfile unik kanggo saben klien: Yen rong klien kanthi riwayat lokal beda njupuk cabang sing padha, server bisa uga kudu nggawe pack beda kanggo saben klien supaya ora ngirim objek sing wis diduweni. Nggawe respons iki mbutuhake CPU lan I/O disk, mula angel nggedhekake kapasitas kanggo nampung akeh klien pamaca.

Minangka gantine, Pando nyedhiyakake model konsistensi sing luwih longgar (konsistensi kausal) kanggo nggedhekake kapasitas nulis, lan nggunakake maneh packfile kanggo nggedhekake kapasitas maca.

Nalika klien nindakake push menyang cabang, Pando nyimpen packfile sing mlebu minangka blob sing ora bisa diowahi ing panyimpenan blob. Saben cabang owah, Pando nyathet versi ref ing panyimpenan metadata, sing ngemot pucuk anyar, pack sing nyedhiyakake pucuk mau, lan versi ref sadurunge sing dadi dependensi pack kasebut. Panyimpenan blob lan panyimpenan metadata padha bisa digedhekake sacara horisontal.

Njupuk commit utawa referensi saka Pando mbutuhake ngetrapake maneh sakumpulan versi ref (packfile) ing klien, kanggo mbangun maneh kahanan klien sing nggawe versi ref sing dijupuk. Iki menehi konsistensi sing luwih longgar ing saindhenging gudang kode, nanging tetep njamin serializabilitas kanggo nganyari saben ref. Klien mung ngalami konflik nalika nindakake push menyang ref sing padha ing wektu sing padha. Klien sing maca sawetara cabang ora bisa nganggep yen asil wacan kasebut nggambarake siji titik wektu ing saindhenging gudang kode.

Iki minangka wujud konsistensi kausal. Kanggo njupuk referensi, pamaca ndeleng riwayat panulis sing ngasilake referensi kasebut. Sajrone push, Pando ngatur riwayat bebarengan sing disepakati klien lan server, supaya klien ngasilake packfile sing luwih gampang dienggo bareng.

Akibate, Pando ora nyedhiyakake kahanan kabeh referensi ing siji titik wektu sajrone operasi Git, utawa urutan nganyari ref sajrone clone utawa fetch. Tuladhane, upamane cabang foo lan bar padha dianyari sajrone negosiasi clone lengkap. Sajrone negosiasi, siji klien bisa ndeleng foo ing versi 1 lan bar ing versi 2, dene klien liyane ndeleng foo ing versi 2 lan bar ing versi 1. Ing praktik, pangguna lan agen ora gumantung marang urutan global nganyari ref, nanging gumantung marang urutan nganyari siji referensi.

Ing simulasi telung model konsistensi iki, kita ngatur 1.000 klien supaya saben klien milih cabang sing beda banjur bola-bali nindakake push commit unik. Kita ngukur total wektu nyata sing dibutuhake lan latensi saka push nganti fetch. Metrik sing pungkasan iki penting kanggo beban kerja, amarga ngukur wektu bolak-balik sing dibutuhake pangguna lan agen kanggo kolaborasi utawa nggunakake sistem liyane sing gumantung marang kontrol versi. Simulasi iki momodelake piranti keras wiwit mesin virtual lan sistem panyimpenan blob kelas umum nganti premium. Ing simulasi iki, kita nglonggarake konsistensi saindhenging gudang kode kanggo commit telung fase.

Sistem commit telung fase sing dimodelake nuduhake latensi nulis sing luwih dhuwur banget nalika ana beban amarga diske wis kebak aktivitas; dene sistem write-ahead log nuduhake latensi maca sing luwih dhuwur banget amarga sebab sing padha, amarga server angel ngimbangi maca saka jurnal. Ing uji nyata ing monorepo kita lan ing simulasi iki, Pando bisa nyengkuyung ewonan klien sing nindakake push bebarengan tanpa nyuda kinerja nalika ana beban.

Nalika nangani push, Pando mriksa validitas packfile sing mlebu sinambi ngalirake menyang panyimpenan blob, tanpa mbongkar menyang gudang kode lokal. Nalika klien miwiti fetch, Pando milih pack sing wis disimpen lan dibutuhake pamaca, banjur pamaca ngundhuh pack kasebut. Ora ana server sing kudu ngetrapake packfile menyang gudang kode lokal utawa nindakake operasi mbongkar lan ngemas sing boros sumber daya. Amarga tugas utama server iki yaiku negosiasi lan milih packfile, server Pando bisa lumaku ing piranti keras kelas umum.

Iki ngidini Pando nggedhekake kapasitas nganti tekan watese klien, jaringan antarane klien lan Pando, lan layanan panyimpenan blob. Yen kapasitase cukup, saben klien sing nggarap cabang mandiri bisa ngirim pack kanthi kacepetan maksimal sambungane dhewe. Kanggo nglayani luwih akeh klien kanthi kacepetan kasebut, kita bisa nambah server Pando lan nggedhekake panyimpenan metadata lan blob bebarengan.

Agen nyunting file lan nggawe commit sacara lokal banjur nglakokake git push, sing nggawe packfile saka owah-owahan kasebut kanggo nganyari cabang. Pando nampa pack lan ngalirake menyang panyimpenan blob. Sawise mriksa validitas push sing mlebu nganggo dekode sapisan liwat, Pando nggunakake transaksi multi-kunci kanggo nyathet versi ref ing panyimpenan metadata kita lan nganyari panuding ref kanthi atomik. Iki ngidini Pando nyedhiyakake konsistensi “maca asil tulisanmu dhewe”. Sakabehe operasi nulis iki mbutuhake $O(1)$ operasi maca lan nulis metadata.

Nalika klien liyane njupuk cabang kasebut, Pando milih sakumpulan pack sing wis disimpen adhedhasar riwayat sing wis diduweni klien. Operasi iki mbutuhake $O(\log \Delta)$ operasi maca metadata, kanthi $\Delta$ minangka jarak paling cendhak ing versi ref antarane sing diduweni lan sing dikarepake klien. Server ngasilake URI packfile, banjur klien ngundhuh liwat layanan Express, sing nyimpen packfile ing cache regional.

Rancangan iki gumantung marang telung layanan utama ing arsitektur Pando: push, fetch, lan kompaksi.

Nalika klien nindakake push, server Git konvensional kaya pemain poker sing mbukak kabeh kertune, nuduhake saben cabang sing diduweni marang klien. Klien banjur nglumpukake commit, tree, lan blob kanggo nggawe packfile sing ora ngemot objek sing wis dingerteni ana ing server.

Mewartakake luwih akeh ref bisa nyilikake ukuran push. Nanging, iki uga bisa ndadekake pack luwih angel digunakake maneh, amarga klien liyane bisa uga durung duwe objek sing ora dilebokake panulis.

Pando nggunakake pendekatan sing beda. Tinimbang mbukak kabeh kertune, Pando mung mewartakake sawetara cabang pilihan marang klien. Iki ditindakake amarga rong alasan:

1. Nyedhiyakake gambaran sing konsisten saka saben ref mbutuhake sumber daya gedhe. Kanthi jutaan cabang, data pawarta ref wae bisa ngluwihi 100 MiB. Kanggo nyedhiyakake iki, saben server kudu njaga pemetaan paling anyar sing mbutuhake biaya koordinasi gedhe, utawa nglakokake kueri basis data sing bebane mundhak manut cacahe ref.

2. Kanthi mung menehi sawenehing ref marang klien, klien bakal ngasilake pack sing mung gumantung marang objek sing kanthi cetha diidinake server supaya ora dilebokake. Nglacak dependensi ngidini Pando nggunakake maneh packfile sing digawe klien ing siji push minangka respons kanggo fetch sabanjure.

Saya akeh ref sing diwartakake server Git, saya akeh sumber sing bisa dadi dhasar klien kanggo ora nglebokake objek nalika push, saengga pack sing diasilake luwih cilik. Nanging, kanggo nggunakake maneh packfile iki, server kudu bisa mbuktekake yen klien sing nindakake fetch duwe saben dependensine. Yen ora, packfile bisa ora ngemot objek sing dibutuhake klien.

Kosok baline, yen server Git ora mewartakake ref babar pisan, klien bakal ngasilake packfile sing ngemot kabeh riwayat gudang kode. Packfile kasebut bisa digunakake klien liyane sapa wae, nanging bebane gedhe amarga njupuk cabang apa wae ateges padha karo clone lengkap.

Kanthi gawan, nalika klien nindakake push cabang fitur anyar, Pando mung mewartakake siji cabang trunk sing wis ditemtokake minangka dhasar. Iki njaga ukuran pawarta tetep padha sanajan cabang ing gudang kode saya akeh, nanging ana kompromine. Nalika insinyur nindakake push bola-bali menyang siji cabang, utawa numpuk siji cabang fitur ing ndhuwure cabang fitur liyane, klien kudu ngirim maneh kabeh sing ana ing njaba trunk.

Akibate, push cabang sing sabanjure dadi luwih gedhe, bisa ngemot objek sing bola-bali, lan nggunakake bandwidth klien tambahan. Ing monorepo kita, median ukuran packfile sing diasilake kanthi cara iki kurang saka 20 KiB, lan persentil kaping 99 kurang saka 3 MiB. Tumrap kita, iki kompromi sing trep amarga pamaca sing wis duwe riwayat trunk sing diwartakake bisa njupuk cabang mung nganggo siji packfile kasebut.

Sawise milih kumpulan ref sing arep diwartakake marang klien, Pando nampa push lan nganyari panyimpenan metadatane. Pando mbagi proses nganyari metadata dadi bagean sinkron lan asinkron. Nganyari metadata kanthi sinkron njamin klien bisa langsung njupuk commit sing lagi wae dianyari. Proses iki nulis versi ref anyar lan nganyari pemetaan panuding ref menyang versi anyar kasebut, kanthi nyimpen pucuk anyar, dependensi sing digunakake kanggo negosiasi packfile, lan pranala menyang packfile sing dikirim liwat push.

Ing wektu sing padha, pakaryan asinkron uga dicathet ing transaksi sing padha, kayata gawe jadwal kompaksi. Kanggo push sing gedhe banget, mung sawenehing commit sing ditulis kanthi sinkron. Iki ndadekake cacah operasi maca lan nulis menyang panyimpenan metadata tetep konstan, sepira wae ukuran push.

Sing penting, server Pando bisa nampa push menyang ref sing ora gegandhengan kanthi mandiri. Siji-sijine kunci sing dadi rebutan yaiku panuding ref, sing kita lindhungi nganggo operasi atomik sing meh padha karo compare-and-swap. Kita bisa nggedhekake kapasitas pangolahan nulis kanthi nambah server Pando, unit kapasitas panyimpenan metadata, utawa panyimpenan blob.

Nalika klien nindakake fetch, klien menehi rong kumpulan ID commit marang server, sing ing protokol diarani have lan want. Ing server Git konvensional, server ngitung selisih kumpulan objek sing bisa digayuh saka have lan saka want, ngompres, banjur ngirim asile marang klien. Sanajan server Git sumber terbuka duwe maneka indeks lokal kanggo nyepetake operasi iki, ngitung packfile iki bisa mbutuhake sumber daya gedhe lan umume angel disimpen ing cache kanthi efektif.

Minangka gantine, Pando nggunakake pemetaan commit sing dicathet nalika push kanggo nggoleki have lan want klien, banjur nemtokake kumpulan versi ref sing ngemot commit kasebut. Saben versi ref kasebut nyambung menyang packfile sing sadurunge wis ditampa Pando. Server nggunakake iki kanggo nemtokake kabutuhan klien, kanthi milih packfile sing nyakup kumpulan objek sing dibutuhake.

Protokol Git mung ngidini siji packfile dikirim ing respons HTTP nalika clone utawa fetch. Nanging, fitur protokol Git sing durung akeh digatekake, packfile-uri, ngidini server ngasilake pranala kanggo ngundhuh pack tambahan kanthi kapisah. Pando mung nggunakake cara iki, lan ngirim packfile kosong langsung ing respons. Kanggo nyengkuyung fitur iki, OpenAI nyumbang sawetara paningkatan packfile-uri marang proyek induk.

Sistem OpenAI lumaku ing akeh wilayah geografis, mula kita njaga klaster Pando kanthi cache lokal ing saben wilayah. Layanan pangiriman pack, Express, nggawe cache kanggo panyimpenan blob kita, lan layanan kapisah nggawe cache kanggo panyimpenan metadata. Cache iki ngidini Pando nglayani panjaluk ID commit utawa operasi maca ref khusus sakabehe saka kahanan sing disimpen ing cache klaster kasebut. Kita nggunakake hashing konsisten kanggo ngarahake panjaluk packfile menyang server Express, kanthi tingkat kasil njupuk saka cache ngluwihi 99%.

Sistem cache iki menehi kapasitas pangolahan sing dhuwur banget, nganti bisa nggunakake kabeh kapasitas jaringan antarane klien lan Pando. Kanthi URI packfile lan cache lokal iki, kita wis mbuktekake yen mung nganggo mesin virtual standar saka panyedhiya cloud, operasi clone lan fetch bisa nggunakake kabeh kapasitas sambungan jaringan 10 Gbps.

Kanggo umume server Git, ngemas maneh lan ngresiki data sing ora dienggo dibutuhake kanggo njaga kinerja gudang kode sing saya gedhe. Loro langkah iki mbebasake papan panyimpenan, nanging mbutuhake komputasi lan I/O sing akeh.

Ing gudang kode sing cepet owah kaya monorepo OpenAI, ora praktis yen kudu ngirim URI packfile dhewe kanggo saben push sing kedadeyan wiwit fetch pungkasan. Saben dina, klien kudu ngundhuh puluhan ewu packfile supaya trunke bisa nggayuh kahanan paling anyar.

Minangka gantine, Pando nggabungake pack ing latar mburi kanggo nyuda beban tambahan iki, kanthi rancangan sing padha karo kompaksi ing log-structured merge-tree. Saben push ngasilake packfile sing diarani “L0” dening Pando, yaiku unit data paling cilik sing bisa dikirim Pando. Suwe-suwe, proses latar mburi nglumpukake packfile iki dadi kumpulan cakupan sing nyakup urutan versi ref, kanthi ukuran sing mundhak sacara geometris saka L0. Saiki, monorepo kita nggunakake kumpulan cakupan packfile nganti L4.

Kumpulan cakupan iki nduweni rong fungsi. Sawise kumpulan cakupan cukup kebak, proses kompaksi bakal njupuk alih lan ngasilake siji packfile. Iki ningkatake rasio kompresi kanthi nata maneh objek ing njero packfile. Nanging, iki uga ningkatake kinerja negosiasi fetch amarga tumindak minangka skip list kanggo versi ref. Kanthi mindhai indeks ing saben tingkat bebarengan, Pando bisa milih kumpulan pack kanggo dikirim marang klien ing wektu logaritmis. Kumpulan cakupan packfile iki, wis dikemas maneh utawa durung, menehi solusi perencanaan fetch sing luwih efisien, nyuda kabutuhan kapasitas pangolahan lan latensi kanggo Pando.

Beda karo akeh server Git, packfile tetep disimpen ing saben tingkat lan ora dibuwang utawa diresiki minangka data sing ora dienggo. Pack ing saben tingkat terus digunakake kanggo nglayani klien, adhedhasar have lan want sing diajukake nalika fetch. Lan kanggo klien sing nggunakake Pando minangka API, maca objek sembarang saka packfile cenderung mbutuhake data luwih sithik saka L0 tinimbang L4, amarga luwih cilik kamungkinane objek kasebut dikompres.

Kompaksi ing Pando nyuda banget total ukuran data sing dikirim marang klien, lan ndadekake beban perencanaan pack mundhak kanthi sublinear marang sepira adohe klien ketinggalan. Iki penting banget kanggo gudang kode gedhe sing cepet owah, sing miturut pangira kita bakal dadi kahanan lumrah anyar ing pangembangan piranti lunak.

Kita mbangun Pando nganggo Codex, saka wiwitan nganti digunakake ing produksi, mung sajrone 10 minggu. Inti Pando dirancang dening siji insinyur, diwujudake dening tim-tim agen, lan dipasang dening sawetara insinyur. Pando wiwit nglayani lalu lintas produksi ing sasi April taun iki, lan dadi salah siji bagean saka sistem piranti pangelolaan kontrol kode sumber sing luwih gedhe ing OpenAI.

Kita nggunakake maneka pendekatan nalika nguji validitas rancangan Pando. Kita ngetrapake prinsip kanggo mbangun dhasar piranti lunak sing luwih aman⁠. Amarga iki proyek anyar saka nol, kita milih mbangun Pando nganggo Rust lan tanpa dependensi lawas. Kita nulis kumpulan uji kesesuaian supaya agen bisa nguji owah-owahane marang prilaku standar Git. Kita uga ngembangake kerangka uji simulasi deterministik kanggo mriksa invarian lan sipat sistem, saengga bisa nemokake lan nyuda race condition sing angel katon sarta regresi ing negosiasi lan perencanaan pack.

Akeh model sing nyumbang kanggo sistem iki; nalika model anyar kasedhiya, kita nggunakake kanggo ningkatake kinerja lan keandalan Pando. Nganggo GPT‑6 Astra, agen nulis Lean lan TLA+ kanggo ngrumusake “teori Pando” kanthi formal, sing kita gunakake kanggo nemokake lan ndandani bug ing implementasi, sarta mbuktekake sipat sistem. Sawetara sesi terus lumaku nganti atusan jam kanggo nemokake lan ndandani kasus langka ing Pando. Kita uga nglakokake agen rina wengi kanggo nguji keamanan Git lan Pando kanthi simulasi serangan nganggo model sing nduweni kapabilitas Daybreak.

Nalika wiwitan, kita ngetrapake Pando minangka proksi sing nerusake operasi maca lan nulis menyang sistem kontrol kode sumber sing wis ana. Iki ngidini kita njaga Pando lan sistem sadurunge tetep sinkron, supaya lalu lintas bisa dialihake menyang Pando kanthi aman tanpa mandheg layanan.

Minangka bagean saka rancangan cache, Pando uga bisa mbusak duplikasi lan nggabungake panjaluk sadurunge diterusake liwat proksi. Iki ngidini piranti sing wis ana tetep lumaku kanthi becik nalika kita mindhah sistem menyang Pando siji mbaka siji. Nalika luwih akeh beban kerja dipindhah menyang Pando, push saka beban kerja kasebut ngisi cache Pando lan ningkatake keandalan backend sadurunge.

Kanggo ngoptimalake kinerja nalika nggunakake Pando, kita wiwit nyebarake distribusi Git publik kita menyang mesin pangembang lan ing aplikasi desktop ChatGPT. Kanggo mindhah klien menyang Pando, kita nggunakake pambungkus internal kanggo CLI Git supaya migrasi klien bisa ditindakake kanthi bertahap. Kita nggawe akeh piranti liyane kanggo nangani panjaluk owah-owahan, tinjauan kode, lan API kanggo otomatisasi. Bebarengan karo lalu lintas Git, kita mindhah atusan integrasi sing gumantung marang API lawas, webhook, lan undhuhan gudang kode.

Codex dhewe mbantu pangembang lan tim nindakake pamindhahan iki. Kita nggawe skill kanggo nyiapake checkout sing wis ana lan nuntun agen nggunakake sistem anyar. Asile, pangembang cukup njaluk Codex supaya mindhah lingkungan pangembangan lan layanane.

Ngalih menyang Pando ningkatake keandalan merge lan nyuda median latensi push meh 80%.

Pando bisa ngirim sak petabyte data Git saben dina mung nganggo sawetara inti CPU. Pando wis ngirim luwih saka 57 terabyte pack Git sajrone sak jam, kanthi luwih saka 99% byte kasebut saka cache disk lokal.

Nggunakake maneh pack ngidini akeh klien ngundhuh riwayat gudang kode sing padha kanthi komputasi sithik ing simpul sing nglayani. Tuladha iki nuduhake siji gudang kode, nanging Pando dirancang kanggo nyengkuyung luwih akeh maneh. Nalika kabutuhan mundhak, kita bisa nggedhekake kapasitas pangiriman data lan negosiasi Git kanthi kapisah.

Mbangun Pando nganggo protokol lan klien Git mbantu kita ngenali bug lan kesempatan kanggo ningkatake kinerja Git dhewe.

Contone, Pando ngirim pack sing bisa digunakake maneh langsung marang klien, mula ngundhuh lan ngindeks pack kasebut dadi bagean utama kanggo nggawe sistem sing cepet lan andal. Pakaryan kasebut mbukak kasus langka ing undhuhan bebarengan, reresik sawise transfer kepedhot, lan nerusake undhuhan sing sejatine wis rampung. Kita ndandani alur kasebut, nambah pamriksan validitas nalika nampa pack sing wis ana kanggo fetch, lan nyumbangake asil pakaryan kasebut bali menyang proyek induk.

Kita uga kudu ngerti wektu lan bandwidth digunakake kanggo apa, mula kita nambah pelacakan undhuhan packfile-uri lan cacah byte kanggo nggawe pack. Iki nggampangake mbedakake apa fetch sing alon ngentekake wektu kanggo nggawe pack utawa ngirim pack.

Ing rakitan Git OpenAI⁠(mbukak ing jendhela anyar), klien bisa ngundhuh lan ngindeks pack mandiri kanthi paralel. Kita nambah konsep “have eksplisit” supaya server bisa mewartakake pucuk cabang saiki kanthi kapisah saka riwayat sing oleh ora dilebokake ing pack dening klien sing nindakake push. Ing Pando, iki ngidini klien nggunakake --force-with-lease kanggo mriksa yen cabang fitur durung owah lan nggawe pack mung adhedhasar trunk. Sapa wae sing duwe riwayat trunk kasebut banjur bisa njupuk cabang nganggo pack sing padha.

Sawetara paningkatan iki wis mlebu ing proyek induk Git, lan akeh liyane ana ing gudang kode publik kita. Kita terus makarya bareng komunitas Git supaya paningkatan iki uga migunani ing njaba Pando. Kowe bisa ngetutake pakaryan kasebut ing pelacak patch publik kita⁠(mbukak ing jendhela anyar).

Kanthi nimbang maneh pandangan umum babagan cara nggedhekake gudang kode Git, Pando ngidini kita nggedhekake monorepo tanpa ngganti alur kerja Git sing wis digunakake para insinyur lan agen kita. Ing monorepo kita, Pando ngidini luwih akeh pakaryan lumaku bebarengan, ningkatake keandalan merge, lan nyepetake wektu kanggo nerbitake owah-owahan kode. Saliyane ing monorepo, kita uga lagi njajaki panggunaan liyane kanggo Pando ing OpenAI, kalebu beban kerja sing mbutuhake akeh agen kolaborasi ing gudang kode Git bebarengan.

Nalika insinyur lan agen ngasilake luwih akeh piranti lunak, luwih akeh tim ing njaba OpenAI bakal nemoni watesan kontrol kode sumber sing wis kita alami. Saiki kita lagi njajaki cara kanggo nuduhake teknologi sing dadi dhasare Pando marang para pangguna.

Pando dibangun adhedhasar pengalaman rong dasawarsa saka pangguna lan pangelola gudang kode Git. Kita bakal terus ngembangake Pando sinambi makarya bareng komunitas Git sumber terbuka kanggo nuduhake paningkatan sing migunani tumrap pangguna Git kanthi luwih jembar.