Monorepo vs polyrepo: web, mobil ve backend’i senkron tutmak

Gerçek sorun: üç kod tabanında değişiklikleri teslim etmek\n\nEkipler monorepo vs polyrepo üzerinde Git felsefesi yüzünden tartışmazlar. Tartışmaların nedeni küçük bir ürün değişikliğinin web, mobil ve backend olmak üzere üç ayrı değişikliğe dönüşmesi ve arada bir şeylerin bozulmasıdır.\n\nİlk bozulan nadiren UI’dır. Genellikle görünmez tutkal bozulur: API sözleşmesi eşleşen bir güncelleme olmadan değişir, paylaşılan bir kütüphane bir yerde yükseltilir ama diğerinde değil, ya da derleme hattı aniden yeni bir adım ister. Bir parça diğerlerinden daha erken yayımlanırsa kullanıcılar bunu “buton web’de var ama mobil uygulama desteklenmiyor diyor” ya da “uygulama sonsuza kadar yükleniyor çünkü backend yanıtı değişti” gibi hatalar olarak hisseder.\n\nWeb, mobil ve backend ayrıca farklı yayın saatlerinde çalışır. Web günde birçok kez gönderebilir. Backend sık gönderebilir ama dikkatli yayılım gerektirir. Mobil en yavaştır çünkü uygulama mağazası incelemesi ve kullanıcı güncellemeleri gerçek gecikme katar. Alan yeniden adlandırmak gibi “basit” bir değişiklik bile, yalnızca bir ekran gerekiyorsa bile, sizi en yavaş hattın temposuna göre plan yapmaya zorlayabilir.\n\nBu durumlar devam ediyorsa muhtemelen bir depo koordinasyon vergisi ödüyorsunuz:\n\n- Kırıcı API değişiklikleri merge’den sonra keşfediliyor.\n- Sürüm hizalaması manuel hatırlatmalara ve tablolar/spreadsheet’lere bağlı.\n- Bir özellik için birden çok koordineli pull request gerekiyor ve birbirini bekliyor.\n- CI yavaş çünkü değişikliğin dokunduğundan çok daha fazlasını derleyip test ediyor.\n- Geri alma riskli çünkü hangi commit’in hangi sürümle eşleştiği belirsiz.\n\nEkip büyüklüğü ve ürün olgunluğu doğru cevabı etkiler. Erken aşamada çoğu ekip koordinasyonu ucuz ve görünürlüğü yüksek tutarak kazanır; işler biraz dağınık olsa bile. Ekipler büyüdükçe sınırlar önem kazanmaya başlar, ama sadece arayüzler stabil ve sahiplik netse.\n\nEğer her anlamlı değişiklik üç yerde de yapılmak zorundaysa, o vergiyi bir şekilde ödersiniz. Depo stratejisi esasen bunu nasıl ödemek istediğinizle ilgilidir.\n\n## Monorepo ve polyrepo temelleri (jargonsuz)\n\nRepo, kodunuzun yaşadığı yer ve geçmişidir. Web, mobil ve backend olduğunda seçim basittir: hepsini bir arada tutmak mı, yoksa ayırmak mı?\n\nBir monorepo birden çok uygulamayı ve genellikle paylaşılan kodu barındıran tek bir depodur. Web, iOS/Android, backend servisleri ve paylaşılan kütüphaneler yan yana bulunur.\n\nBir polyrepo bunun tersidir: her uygulama (ve bazen her servis) kendi deposuna sahiptir. Paylaşılan kod genellikle ayrı bir paket olur veya ihtiyaç halinde küçük parçalar kopyalanır.\n\nGünlük kullanımda monorepolar genellikle şöyle hissettirir: kod paylaşımı kolaydır, çapraz uygulama değişiklikleri tek bir pull request olabilir ve kurallar tutarlıdır. Dezavantaj sosyal olur: sahiplik bulanıklaşabilir, net sınırlar koymazsanız depo genelindeki kontroller katı gelebilir.\n\nPolyrepolar genellikle şöyle hissedilir: her ekip bağımsız hareket edebilir, repolar odaklı kalır ve erişim kontrolleri daha basit olabilir. Dezavantaj koordinasyondur: kod paylaşımı planlamayı gerektirir ve çapraz uygulama değişiklikleri çoğunlukla birden çok pull request ve dikkatli zamanlama olur.\n\nBirçok ekip hibrit bir çözümle biter: uygulamalar ayrı repolarda, paylaşılan sözleşmeler bir yerde; veya güçlü sınırlarla tek bir monorepo ki her ekip çoğunlukla kendi alanında kalsın.\n\nEğer backend, web ve mobil tek bir doğruluk kaynağından üreten bir platform kullanıyorsanız, sözleşmeler ve mantık birlikte yaşadığı için sürüklenmeyi azaltırsınız. AppMaster, örneğin, tek bir modelden üretim hazır backend, web ve native mobil uygulamalar üretebilir. Bu, yayın gerçeklerini (mobil hâlâ daha yavaş gönderir) ortadan kaldırmaz ama “üçünü de güncelledik mi?” yükünün çoğunu kaldırabilir.\n\n## Bağımlılık yönetimi: paylaşılan kodu güvenli tutmak\n\nPaylaşılan kod, ekiplerin zaman kaybettiği yerdir; depo düzenine bakılmaksızın. Paylaşılan bir kütüphanedeki veya API sözleşmesindeki küçük bir değişiklik web build’lerini, mobil sürümleri ve backend deploy’larını farklı şekillerde bozabilir.\n\nKütüphaneleri paylaşırken (UI bileşenleri, doğrulama kuralları, kimlik yardımcısı gibi) herkes için tek sürüm mü yoksa zaman içinde birden fazla sürüm mü kullanacağınıza karar vermiş olursunuz.\n\n- Tek sürüm daha basittir ve “kendi branşımda çalışıyor” sürprizlerini önler.\n- Birden fazla sürüm ekiplerin kendi hızında ilerlemesini sağlar ama karmaşa yaratır ve güvenlik düzeltmelerini yaymayı zorlaştırır.\n\nAPI istemcileri ve şemalar ekstra özen ister. Manuel güncellemeler yavaş ve hata yapmaya müsaittir. Daha iyi bir desen API şemasını tek gerçeklik olarak kabul edip istemcileri ondan üretmektir; bunları ya kontrol edip repoya dahil edin ya da CI’da üretin. Amaç hızlı başarısız olmak: backend zorunlu bir alan eklerse, mobil istemci derlemede kırılmalı, test ortamında veya üretimde üç gün sonra değil.\n\nDavranış değişiklikleri güvenli bir geçiş yolu olmadan yayıldığında kırılmalar olur. Önce ekleyici değişiklikleri tercih edin (yeni alanlar, yeni uç noktalar), sonra kullanım dışı bırakın. Eğer bir şeyi kırmak zorundaysanız, sürümlü uç noktalar veya kısa bir uyumluluk penceresi kullanın.\n\nSomut örnek: backend status alanının adını state olarak değiştirir. Web bugün güncelliyorsa ama mobilin gönderimi bir hafta sürecekse, backend o hafta boyunca her iki alanı da kabul etmeli ya da eski alanı yeni alana eşleyen bir adaptör yayımlamalıdır.\n\nBağımlılık güncellemelerini sıkıcı (iyi anlamda) tutacak birkaç kural:\n\n- Bir takvime göre güncelleyin. Küçük haftalık güncellemeler büyük üç aylık güncellemelerden iyidir.\n- Kırıcı değişiklikler için açık onay şartı ve kısa bir geçiş notu isteyin.\n- Kontrolleri otomatikleştirin: bağımlılık yükseltmeleri, istemci üretimi ve temel sözleşme testleri.\n\nÜretilen kod sürüklenmeyi azaltabilir ama disiplini yerine geçirmez. Tek bir sözleşmeye, net kullanımdan kaldırma politikalarına ve öngörülebilir güncellemelere hâlâ ihtiyacınız var.\n\n## Sürüm koordinasyonu: web, mobil ve backend’i hizalamak\n\nSürüm koordinasyonu depo stratejisinin teoriden pratiğe geçtiği yerdir. Backend bir API alan adını değiştirdiğinde, web uygulaması genellikle aynı gün güncelleyip gönderebilir. Mobil uygulamalar farklıdır: uygulama mağazası incelemesi ve kullanıcı güncelleme zamanlaması küçük bir uyumsuzluğu bir hafta boyunca destek taleplerine dönüştürebilir.\n\nPratik hedef basittir: kullanıcı bir eylem gerçekleştirdiğinde hangi parça önce güncellenmiş olursa olsun işlem doğru çalışmalı. Bu, kusursuz senkronize sürümlere dayanmak yerine karışık sürümler için plan yapmak anlamına gelir.\n\n### Ekiplerin gerçekten kullandığı sürümleme modelleri\n\nÇoğu ekip şu yaklaşımlardan birine yerleşir:\n\n1) Tek paylaşılan sürüm treni: web, mobil ve backend tek bir sürümlü birim olarak gönderilir.\n\n2) Hizmet başına sürümler ve uyumluluk kuralları: her uygulama/servisin kendi sürümü vardır ve backend tanımlı bir istemci sürümleri aralığını destekler.\n\nTek paylaşılan sürüm treni düzenli görünür ama mobil gecikmeleri altında sıklıkla aksar. Hizmet başına sürümler kağıt üzerinde daha karmaşık görünür ama gerçeğe daha yakındır. Eğer hizmet başına gidecekseniz bir kural yazın ve uygulayın: hangi backend sürümleri hangi mobil sürümleri desteklemeli ve ne kadar süre.\n\nMobil gecikmeleri ayrıca hata düzeltmelerini nasıl ele aldığınızı değiştirir. Backend acil düzeltmeleri hızlıca yayımlayabilir; mobil düzeltmeler kullanıcıya ulaşmak için günler sürebilir. Eski mobil derlemelerin çalışmaya devam etmesini sağlayacak sunucu tarafı düzeltmeleri tercih edin. İstemci değiştirmek zorundaysanız feature flag kullanın ve eski alanları kullanıcıların güncellediğini görene kadar kaldırmaktan kaçının.\n\nÖrnek: sipariş akışına “teslimat talimatları” eklersiniz. Backend isteğe bağlı yeni alan ekler, web hemen gösterir, mobil bir sonraki sprintte gösterir. Backend eski istekleri kabul eder ve alan isteğe bağlı kalırsa mobil yetişene kadar her şey çalışmaya devam eder.\n\n### Sürüm takvimine kim sahip olmalı\n\nKoordinasyon “herkesin işi” olduğunda aslında kimsenin işi olmaz. Sahip tech lead, sürüm yöneticisi veya güçlü mühendislik desteği olan bir ürün yöneticisi olabilir. Görevleri sürüm beklentilerini görünür ve tutarlı tutmaktır.\n\nKompleks bir süreç gerekmez. Tek başına tekrarlanabilir birkaç alışkanlığa ihtiyaç vardır: kesme ve dondurma tarihleri içeren basit bir sürüm takvimi, API değişiklikleri öncesi hızlı bir ekipler arası kontrol ve mobil geciktiğinde ne olacağına dair net bir plan (backend’i tutmak mı yoksa uyumluluğu korumak mı).\n\nEğer iş akışınız web, mobil ve backend’i tek bir modelden üretiyorsa, yine de bir sürüm sahibine ihtiyacınız olur. Genellikle “üç yeri de güncelledik mi?” anları azalır ama mobil zamanlamasından kaçamazsınız.\n\n## CI süresini yönetmek\n\nCI her iki düzende de aynı nedenlerle yavaşlar: çok fazla yeniden derleme yapıyorsunuz, bağımlılıkları tekrar tekrar yüklüyorsunuz ve her değişiklikte tüm testleri koşturuyorsunuz.\n\nYaygın zaman yiyiciler arasında küçük değişiklikler için tam derlemeler, eksik önbellekler, her şeyi çalıştıran test süitleri ve paralel çalıştırılabilecek işler vardır.\n\nHerkese yardımcı olacak iyileştirmelerle başlayın:\n\n- Bağımlılık indirmelerini ve derleme çıktıları için önbellek kullanın.\n- Lint, birim testleri ve derlemeleri mümkünse paralel çalıştırın.\n- Hızlı kontrolleri (her commit) daha yavaş kontrollerden (ana dal, gece veya sürüm öncesi) ayırın.\n\n### Monorepo taktikleri\n\nMonorepolar her commit’te “tüm dünyayı derle” pipeline’ı tetiklediğinde sıkıcı olur. Çözüm, sadece değişiklikten etkilenenleri derlemek ve test etmektir.\n\nYol filtreleri ve sadece etkilenen yaklaşımı kullanın: mobil UI kodunu değiştirdiyseniz backend imajlarını derlemeyin. Paylaşılan bir kütüphaneyi değiştirdiyseniz onu kullanan uygulamaları derleyin ve test edin. Birçok ekip bunu basit bir bağımlılık grafiğiyle formalize eder ki CI karar verebilsin.\n\n### Polyrepo taktikleri\n\nPolyrepolar küçük oldukları için hızlı olabilir, ama genellikle çoğaltma ve tutarsız araç zincirleri yüzünden zaman kaybederler.\n\nTek bir ortak CI şablonu tutun (aynı adımlar, aynı önbellekler, aynı konvansiyonlar) ki her repo pipeline’ı yeniden icat etmesin. Araç zincirlerini (runtime sürümleri, derleme araçları, linters) sabitleyerek “bir repoda çalışıyor ama diğerinde çalışmıyor” sürprizlerini önleyin. Bağımlılık indirmeleri darboğazsa ortak önbellekler veya dahili aynalar kurun.\n\nSomut örnek: bir özellik yeni bir “status” alanı ekler. Backend değişir, web gösterir, mobil gösterir. Monorepoda CI backend testlerini ve API istemcisine bağımlı olan web ile mobil parçaları çalıştırmalıdır. Polyrepo kurulumunda her repo kendi hızlı kontrollerini çalıştırmalı ve ayrı bir entegrasyon pipeline’ı üç sürümün hâlâ uyumlu olduğunu doğrulamalıdır.\n\nEğer kaynak kodu dışa aktarıyor ve kendi CI’inizi çalıştırıyorsanız aynı kural geçerlidir: sadece değişeni derleyin, önbellekleri agresif kullanın ve yavaş kontrolleri sadece gerçekten değer kattıklarında çalıştırın.\n\n## Adım adım: ekibinize uygun depo stratejisini seçin\n\nGünlük iş akışınızdan değil ideolojiden başlamadığınızda karar vermek kolaylaşır.\n\n### 1) Birlikte değişmesi gerekenleri yazın\n\nSon 5–10 özelliği seçin ve hangi parçaların birlikte gitmesi gerektiğini not edin. Her birinin UI ekranlarına, API uç noktalarına, veri tablosuna, kimlik/izin kurallarına veya paylaşılan doğrulamaya dokunup dokunmadığını işaretleyin. Çoğu özellik tüm üç alanı koordineli olarak gerektiriyorsa, ayrık bir kurulum, sürüm süreciniz çok disiplinli değilse acı verici olacaktır.\n\n### 2) Paylaşılan kodu ve kararları izleyin\n\nPaylaşılan kod sadece kütüphane değildir; aynı zamanda sözleşmeler (API şemaları), UI kalıpları ve iş kurallarıdır. Bu parçaların bugün nerede yaşadığını, kimlerin düzenlediğini ve değişikliklerin nasıl onaylandığını not edin. Paylaşılan parçalar repolar arasında kopyalanıyorsa, daha sıkı kontrol gerektiğinin işaretidir—ya monorepo ya da sıkı sürümleme kuralları.\n\n### 3) Sınırlar ve sahipler tanımlayın\n\nBirimlerin ne olduğunu (uygulamalar, servisler, kütüphaneler) belirleyin ve her birine bir sahip atayın. Sınırlar depo düzeninden daha önemlidir. Sahiplik yoksa monorepo gürültülü olur. Sahiplik yoksa polyrepo kopuk olur.\n\nBasit bir kontrol listesi isterseniz hedefleyin: her deploy edilebilir servis/uygulama için bir repo veya klasör, paylaşılan sözleşmeler için tek bir yer, gerçekten paylaşılan UI bileşenleri için bir yer, iş mantığının nerede yaşadığına dair net bir kural ve her biri için belgelenmiş bir sahip.\n\n### 4) Takip edebileceğiniz bir sürüm modeli seçin\n\nMobil sürümleri backend değişikliklerinin gerisindeyse, uyumluluk planına ihtiyacınız var (sürümlü API’ler, geriye dönük uyumlu alanlar veya tanımlı destek penceresi). Her şey birlikte gönderilmeliyse sürüm treni işe yarayabilir ama koordinasyon gereksinimini artırır.\n\nBranch kurallarını sıkıcı tutun: kısa ömürlü branch’ler, küçük merge’ler ve net bir hotfix yolu.\n\n### 5) CI’yi yaygın değişikliklere göre tasarlayın\n\nCI’yi ilk günden en kötü duruma göre tasarlamayın. Günlük yapılanlara göre tasarlayın.\n\nÇoğu commit sadece web UI’yi etkiliyorsa, varsayılan olarak web lint ve birim testlerini çalıştırın; tam uçtan uca testleri bir takvimde veya sürümler öncesinde çalıştırın. Olaylar genellikle API sürüklenmesinden kaynaklanıyorsa önce sözleşme testlerine ve istemci üretimine yatırım yapın.\n\n## Örnek: web, mobil ve backend’i etkileyen bir özellik\n\nKüçük bir ekip düşünün: müşteri portalı (web), saha uygulaması (mobil) ve bir API (backend). Gelen istek: işlere yeni “Service status” alanı ekle ve her yerde göster.\n\nDeğişiklik küçük görünebilir ama bu bir koordinasyon testidir. Backend alanı ekler ve doğrulamaları, yanıtları günceller. Web bunu gösterir ve filtreleri günceller. Mobil çevrimdışı göstermek, senkronize etmek ve kenar durumları ele almak zorundadır.\n\nGerçek sorun şu: API değişikliği kırıcıdır. Alan adı statusten service_statuse değişir ve eski istemciler bunu ele almazsa çöker.\n\n### Monorepo neyi değiştirir?\n\nMonorepo burada genellikle daha sakin hissettirir. Backend, web ve mobil güncellemeleri tek bir pull request’te (veya koordineli bir dizi commit’te) yer alabilir. CI etkilenen testleri çalıştırabilir ve üç güncellemeyi içeren tek bir sürüm etiketleyebilirsiniz.\n\nAna risk teknik değil sosyal olur: tek bir repo kırıcı bir değişikliği hızlıca merge etmeyi kolaylaştırır, bu yüzden inceleme kurallarınız güçlü olmalıdır.\n\n### Polyrepo neyi değiştirir?\n\nAyrı repolarda her uygulama kendi takviminde yaşar. Backend önce gönderirse web ve mobil yetişmeye çalışır. Mobil güncellemeleri uygulama mağazası incelemesi gerektiriyorsa “düzeltme” kod küçük olsa bile günler alabilir.\n\nTakımlar bunu genellikle daha fazla yapı ile çözer: sürümlü uç noktalar, geriye dönük uyumlu yanıtlar, daha uzun kullanım dışı bırakma pencereleri ve net yayılım adımları. İşler bu şekilde yürür ama sürekli bakım gerektirir.\n\nKarar verirken son birkaç aya bakın:\n\n- Olaylar sıklıkla uyumsuz sürümlerden mi kaynaklanıyor? O zaman daha sıkı koordinasyonu düşünün.\n- Yayınlar sık ve zaman duyarlıysa (özellikle mobil), kırıcı değişikliklerden kaçının veya bunları merkezileştirin.\n\n## Kaçınılması gereken yaygın hatalar ve tuzaklar\n\nÇoğu ekip “yanlış” depo yapısı seçtiği için değil, günlük alışkanlıklar sürtüşmeyi yavaşça artırdığı için başarısız olur.\n\n### Paylaşılan kod çöplüğe dönüşür\n\nPaylaşılan bir kütüphane caziptir: yardımcılar, tipler, UI parçaları, “geçici” çözümler. Kısa sürede eskimiş kodların saklandığı yer olur ve kimse neyin güvenli olduğunu bilmez.\n\nPaylaşılan kodu küçük ve katı tutun. “Paylaşılan” birçok ekip tarafından kullanılan, dikkatle incelenen ve niyetle değiştirilen şey anlamına gelmelidir.\n\n### Gizli varsayımlarla sıkı bağlılık\n\nAyrı repolarda bile sistemler sıkı bağlı olabilir; bu bağlılık tarihçeye değil varsayımlara kayar: tarih formatları, enum değerleri, izin kuralları ve “bu alan hep var” gibi.\n\nÖrnek: mobil status = 2yi “Onaylandı” olarak ele alır, web bunu “Doğrulandı” olarak görür, backend enum sırasını değiştirir ve her şey rastgele bozuluyormuş gibi görünür.\n\nBunu önlemek için sözleşmeleri (alanların ne anlama geldiği, hangi değerlerin geçerli olduğu) belgeleyin ve bunları ürün kuralları gibi görünür hale getirin.\n\n### Sahipliğin belirsiz olması\n\nHerkes her şeyi değiştirebiliyorsa incelemeler yüzeysel olur ve hatalar kayar. Hiç kimse bir alana sahip değilse hatalar haftalarca bekler.\n\nWeb, mobil, backend ve paylaşılan modüller için sahipler tanımlayın. Sahiplik katkıyı engellemez; değişikliklerin doğru gözden geçirilmesini sağlar.\n\n### CI’nin budanmayıp büyümesi\n\nCI küçük başlar, sonra her olay “güvenlik için” yeni bir iş ekler. Aylar sonra yavaş ve pahalı olur, insanlar CI’den kaçınır.\n\nBasit bir kural yardımcı olur: her CI işi net bir amaca ve sahibi olmalı; gerçek sorunları yakalamıyorsa kaldırılmalı.\n\nUyarı işaretleri: işler arasında tekrar eden testler, günlerce kırık kalan işler, “hızlı değişiklik”leri doğrulamanın derlemekten daha uzun sürmesi ve backend‑sadece değişikliklerde mobil derlemelerinin tetiklenmesi.\n\n### Sürüm koordinasyonu kabile bilgiseliğine dayanması\n\nEğer sürümler bir kişinin hatırladığı sıraya ve gizli püf noktalarına bağlıysa, daha yavaş gönderirsiniz ve daha sık kırarsınız.\n\nSürüm adımlarını yazın, tekrar edilebilir hale getirin ve sıkıcı kontrolleri otomatikleştirin. İş akışınız üretim hazır backend ve istemciler üretiyor olsa bile net sürüm kurallarına ihtiyacınız vardır.\n\n## Repo yapısını değiştirmeden önce hızlı kontroller\n\nRepoları yeniden düzenlemeden önce ekibinizin bugün nasıl gönderdiğini gerçekçi şekilde kontrol edin. Hedef kusursuz yapı değil; bir değişiklik web, mobil ve backend’i etkilediğinde daha az sürpriz yaşamak.\n\nBeş soru sorun:\n\n- Bağımsız gönderim: Bir backend düzeltmesini mobil uygulamayı aynı gün güncellemeye zorlamadan yayımlayabiliyor musunuz?\n- API değişiklik kuralları: Kullanımdan kaldırma ve eski davranışın ne kadar süre destekleneceğine dair yazılı bir sözleşmeniz var mı?\n- Paylaşılan kod disiplini: Paylaşılan kütüphaneler (UI bileşenleri, API istemcileri, iş kuralları) tutarlı şekilde incelenip sürümleniyor mu?\n- CI sadece önemli olanı çalıştırıyor mu: CI neyin değiştiğini anlayıp sadece etkilenen parçaları mı çalıştırabiliyor?\n- Tek bir sürüm görünümü: Sahipleri ve tarihleriyle birlikte web, mobil ve backend’te neyin çıkacağını görebileceğiniz tek bir yer var mı?\n\nBasit örnek: checkout’a yeni bir “adres” alanı ekleniyor. Backend önce gönderilirse eski mobil uygulama yine de çalışmalı. Bu genellikle API’nin eski ve yeni yükleri bir süre kabul etmesi ve istemci güncellemelerinin isteğe bağlı olmasıyla sağlanır.\n\n## Sonraki adımlar: koordinasyon işini azaltın ve güvenle gönderin\n\nAmaç “doğru” depo yapısı değildir. Amaç daha az el değiştirme, daha az sürpriz ve “hangi sürüm canlı?” anlarını azaltmaktır.\n\nKısa bir karar kaydı yazın: mevcut yaklaşımı neden seçtiğiniz, hangi iyileşmeleri beklediğiniz ve hangi ödünleri kabul ettiğiniz. Bunu 6–12 ayda bir veya ekip büyüklüğü ya da sürüm sıklığı değişirse daha erken gözden geçirin.\n\nDosyaları taşımadan önce gerçek ağrıyı azaltan en küçük değişikliği seçin:\n\n- Paylaşılan paketler için sürüm kuralları ekleyin ve uygulayın.\n- API sözleşmelerini tanımlayın ve bunları CI’da sözleşme testleri ile zorlayın.\n- Web, mobil ve backend için ortak bir sürüm kontrol listesinde anlaşın.\n- Birden çok parçayı etkileyen değişiklikler için önizleme ortamları kullanın.\n- CI süre limitleri koyun (örneğin: PR kontrolleri 15 dakikanın altında).\n\nEğer çapraz kod tabanı bağımlılığı gerçek darboğazsa, değişmesi gereken yer sayısını azaltmak depo düzeninden daha etkili olabilir. Bazı ekipler bunu tek bir doğruluk kaynağına daha fazla mantık ve veri modelini taşıyarak yapar.\n\nBu yaklaşımı keşfetmek isterseniz, AppMaster uygulamaları, backend servisleri ve native mobil uygulamaları paylaşılan veri modelleri ve iş mantığıyla üretmek üzere tasarlanmıştır. Değerlendirmek için düşük riskli bir yol, önce küçük bir dahili araç inşa etmek; sonra koordinasyon işini ne kadar azalttığına göre karar verin.\n\nGüvenli yol kasıtlı olarak sıkıcıdır: kararı belgeleyin, bağları azaltın, kontrolleri otomatikleştirin ve sayılar yardımcı olana kadar depo yapısını değiştirmeyin.