İhraç edilen kaynak kodunu açık yönetişim kurallarıyla senkron tutun

Hangi problemi çözüyor (basitçe)

Bir platform uygulamanızı yeniden ürettiğinde kod tabanının büyük bölümlerini yeniden yazabilir. Bu, kodu temiz tutar ama aynı zamanda üretilen dosyalarda yapılan elle düzenlemelerin bir sonraki "regenerate" veya yeni bir yapı yayınlandığında kaybolabileceği anlamına gelir.

Gerçek hedef "hiç kod ihraç etmemek" değil. Amaç, görsel modeli kaynak doğrusu olarak tutmak, böylece değişiklikler tutarlı ve tekrarlanabilir kalsın. AppMaster'da bu model veri şemanızı, iş süreçlerinizi, API uç noktalarınızı ve UI ekranlarınızı içerir. Model doğru kaldığında, yeniden üretim stresli bir olay değil, güvenli ve rutin bir işlem olur.

"İhraç edilmiş kaynak kodu" genellikle üretilen Go backend, Vue3 web uygulaması ve Kotlin/SwiftUI mobil uygulamalarını alıp kontrolünüz altına koymak demektir. Takımlar kodu pratik nedenlerle ihraç eder: güvenlik incelemeleri, kendi barındırma kuralları, özel entegrasyonlar veya platform dışında uzun vadeli bakım gibi.

Sorun, ihraç edilen depo kendi başına yaşamaya başladığında başlar. Birisi üretilen dosyalarda doğrudan bir hata düzeltir, kodda "hızlıca" bir özellik ekler ya da veritabanı katmanını elle değiştirir. Daha sonra model değişir (alan adı değişikliği, yeni bir uç nokta, değiştirilmiş bir iş süreci), uygulama yeniden üretilir ve şimdi sürüklenme, acı veren birleştirmeler veya kaybolan işler ortaya çıkar.

Yönetişim çoğunlukla süreçtir, araç değil. Birkaç temel soruya cevap verir:

• Elle değişikliklere nerede izin veriliyor, nerede yasak?
• Görsel modele karşı ihraç edilmiş repoya kim değişiklik onayı verebilir?
• Neden bir değişiklik kodda yapıldı, modelde değil, bunu nasıl kaydedersiniz?
• Yeniden üretim özel bir uzantıyla çakıştığında ne olur?

Bu kurallar net olduğunda, yeniden üretim risk olmaktan çıkar. Güncellemeleri dağıtmanın güvenilir bir yolu olurken, gerçekten var olması gereken küçük el yazısı parçaları korur.

Kaynak doğrusunu seçin ve ona sadık kalın

İhraç edilen kaynak kodunu yeniden üreten bir platformla senkron tutmak için bir açık varsayıma ihtiyacınız var: değişiklikler nerede yaşar?

AppMaster gibi platformlar için en güvenli varsayılan basittir: görsel model kaynak doğrusudur. Ürünün günlük işleyişini tanımlayan şeyler modelde yaşamalıdır; ihraç edilmiş repoda değil. Bu genellikle veri modeli, iş mantığı, API uç noktaları ve ana UI akışlarını içerir.

İhraç edilen kod hâlâ faydalıdır, ama onu bir build çıktısı ve modelin iyi ifade edemediği işler için açıkça izin verilmiş küçük bir alan olarak değerlendirin.

Bir çok takımın uygulayabileceği politika şu şekildedir:

• Ürün davranışını değiştiriyorsa, modelde olmalıdır.
• Harici bir şeye bağlanan bir konektörse, ince bir adaptör olarak model dışında olabilir.
• Ortak bir yardımcıysa (log ayarları, küçük parse yardımcısı), kütüphane olarak model dışında yaşayabilir.
• Müşteri-özel veya ortam-özel yapılandırmaysa, model dışında tutun ve dağıtım zamanında enjekte edin.
• Performans veya güvenlik düzeltmesi ise önce bunun modelde ifade edilip edilemeyeceğini kontrol edin. Edilemiyorsa, istisnayı belgeleyin.

İzin verilen alanı kasıtlı olarak küçük tutun. Ne kadar büyük olursa, yeniden üretim değişiklikleri üstüne yazma veya gizli sürüklenme oluşturma olasılığı o kadar artar.

Ayrıca istisnalara kimlerin onay verebileceğine karar verin. Örneğin, yalnızca bir teknik lider kimlik doğrulama, veri doğrulama veya çekirdek iş akışlarını etkileyen kod değişikliklerini onaylayabilir. "İstisnanın ne zaman sona ereceği" için basit bir kural ekleyin, örneğin "bir sonraki yeniden üretim döngüsünden sonra gözden geçir", böylece geçici düzeltmeler sessizce kalıcı çatallara dönüşmez.

Kod ihraç etmek ne zaman mantıklıdır (ve ne zaman değildir)

Kaynak kodu ihraç etmek doğru hareket olabilir, ama yalnızca neden yaptığınız ve sonrasında nelerin değişmesini beklediğiniz konusunda netseniz. AppMaster gibi yeniden üreten bir platformla, en güvenli varsayılan görsel modeli kaynak doğrusu olarak kabul etmek ve ihracı incelemek, test etmek ve dağıtmak için bir çıktı olarak görmekti.

İhraç genellikle ekiplerin daha güçlü denetim gerektirdiği, kendi bulutlarında ya da on-prem kurallarına ihtiyaç duyduğu veya yerleşik modüllerle kapsanmayan özel entegrasyon gerektiği durumlarda mantıklıdır. Ayrıca güvenlik ekibiniz kod taraması gerektiriyorsa veya tedarikçi bağımsız bir çıkış planı istiyorsanız faydalı olabilir.

Ana soru şudur: kod erişimine mi yoksa kod düzenlemesine mi ihtiyacınız var?

• Code access only (yalnızca okunur ihraç): denetimler, güvenlik incelemesi, felaket kurtarma, taşınabilirlik, paydaşlara davranışı açıklama.
• Code edits (düzenlenebilir ihraç): kodda olması gereken düşük seviye yeteneklerin eklenmesi, üçüncü parti kütüphaneyi yamalama, modelin ifade edemediği sıkı çalışma zamanı kısıtı karşılanması.

Salt okunur ihraç daha kolaydır çünkü elle yapılan düzenlemelerin üstüne yazılmasından endişe etmeden sık sık yeniden üretebilirsiniz.

Düzenlenebilir ihraç ekiplerin sorun yaşadığı alandır. Uzun ömürlü elle değişiklikler bir geliştirici tercihi değil, bir yönetişim kararıdır. "Bir yıl içinde bu değişiklik nerede olacak?" sorusuna cevap veremiyorsanız sürüklenmeyle sonuçlanırsınız: model bir şey söyler, üretken kod başka bir şey.

İyi işleyen bir kural: değişiklik iş mantığı, veri şekli, UI akışı veya API davranışıysa, modelde tutun. Gerçek bir platform boşluğuysa, kod düzenlemelerine yalnızca açık sahiplik, yazılı bir uzantı deseni ve yeniden üretimin nasıl ele alınacağına dair net bir planla izin verin.

Yeniden üretim sizi bozmasın diye güvenli uzantı noktaları tasarlayın

Üretilen dosyaları "sadece bir küçük değişiklik ekle" yeri gibi görmeyin. Yeniden üretim er ya da geç kazanır.

Başlangıçta görsel modelin sahip olduğu ile ekibinizin sahip olduğu arasında net bir çizgi çizin. AppMaster ile model backend (Go), web (Vue3) ve mobil (Kotlin/SwiftUI) kodlarını yeniden üretebildiği için, üretilen alandaki her şeyin herhangi bir zamanda değiştirilebileceğini varsayın.

Aşılması zor sınırlar oluşturun

Sınırı repoda ve alışkanlıklarda belirgin kılın. Doğru şey zahmetli olduğunda insanlar yanlış şeyi yapar.

Pratikte işe yarayan birkaç koruma:

• Üretilmiş çıktıyı yalnız okunur olarak muamele edilen özel bir klasöre koyun.
• Özel kodu kendi klasöründe, kendi build giriş noktalarıyla tutun.
• Özel kodun, üretilen kodu yalnızca public arayüzler aracılığıyla çağırmasını zorunlu kılın (internal dosyalara değil).
• "do not edit" dosyaları değiştiyse CI başarısız olsun diye bir kontrol ekleyin.
• Üretilen dosyalara açıkça üst bilgi yorumu ekleyin; üzerine yazılacağını net söyleyin.

Son nokta önemlidir. Açık bir "DO NOT EDIT: modelden yeniden üretilir" mesajı iyi niyetli düzeltmelerin gelecekte kırılmalara dönüşmesini engeller.

Düzenlemek yerine sarma tercih edin

Özel davranış gerektiğinde, üretilen kodu değiştirmek yerine onu sarın. "Adapter katmanı" veya üretilen parçalar ile uygulamanız arasında ince bir cephe düşünün.

Örneğin, AppMaster backend'ini ihraç edip üçüncü taraf bir envanter sistemiyle özel bir entegrasyon eklemeniz gerekirse, üretilen uç nokta işleyicisini değiştirmeyin. Bunun yerine:

1. Üretilen uç noktayı olduğu gibi tutun.

2. Envanter API'sini çağıran özel bir servis ekleyin (custom/ alanında).

3. Üretilen mantığın, sizin sahip olduğunuz stabil bir arayüz üzerinden bu servisi çağırmasını sağlayın; örneğin InventoryClient gibi küçük bir paketle.

Yeniden üretim uç nokta implementasyonunu değiştirebilir ama entegrasyon kodunuz sağlam kalır. Sadece arayüz sınırının stabil kalması gerekir.

Mümkün olduğunca stabil entegrasyon noktalarını kullanın

Özel kod yazmadan önce, davranışı API'ler, webhook'lar veya platform modülleri gibi stabil kancalar aracılığıyla iliştirebilip iliştiremeyeceğinizi kontrol edin. Örneğin, AppMaster Stripe ödemeleri, Telegram veya e-posta/SMS için önceden hazırlanmış modüller içerir. Stabil entegrasyon noktalarını kullanmak, yeniden üretimin sizi ne kadar şaşırtabileceğini azaltır.

"edit etmeyin" bölgelerini bir kısa sayfada belgeleyin ve bunları otomasyonla zorlayın. Sadece insanların kafasında olan kurallar teslim tarihleriyle yaşayamaz.

Yeniden üretimi kaldırabilecek depo yapısı

Yeniden üretimi atlatabilen bir repo, bir bakışta neyin üretilmiş, neyin insan tarafından sahiplenilmiş ve neyin konfigürasyon olduğunu gösterir. Eğer biri 10 saniyede söyleyemiyorsa, üzerine yazmalar ve "gizemli düzeltmeler" olur.

AppMaster gibi bir platformdan ihraç ederken, ihracı tekrarlanabilir bir build çıktısı gibi değerlendirin, tek seferlik bir teslim değil.

Pratik bir yapı, kodu sahiplik ve yaşam döngüsüne göre ayırır:

• generated/ (veya appmaster_generated/): yeniden üretilebilecek her şey. Elle düzenleme yok.
• custom/: tüm el yazısı uzantılar, adaptörler ve birleştirici kodlar.
• config/: ortam şablonları, dağıtım ayarları, gizli yer tutucuları (gerçek gizli bilgiler değil).
• scripts/: "regen + patch + test" gibi otomasyonlar.
• docs/: repo için kısa kurallar sayfası.

İsimlendirme kuralları aceleyle iş yapanlarda yardımcı olur. Özel parçalar için tutarlı bir önek kullanın (custom_ veya ext_) ve yalnızca gerçekten yardımcıysa üretilen düzeni aynalayın. Bir üretilen dosyaya "sadece bu sefer" dokunma isteği gelirse durun ve o değişikliği custom/ içine veya üzerinde anlaşılmış bir uzantı noktasına taşıyın.

Branchleme aynı ayrımı yansıtmalı. Birçok ekip iki tür işi görünür tutar: model odaklı değişiklikler (görsel model güncellemeleri) ve özel kod değişiklikleri (uzantılar). Tek bir repoda bile PR etiketleri veya model/* ve custom/* gibi branch isimlendirmeleri incelemeleri daha net yapar.

Sürümler için "taze yeniden üretim" pazarlık dışı olsun. Sürüm adayı generated/ içine yeniden üretilerek başlamalı, script'lenmiş yamalar uygulanmalı ve testler çalıştırılmalıdır. Eğer sıfırdan yeniden oluşturulamıyorsa, repo zaten sürüklenme yaşıyor demektir.

Model ve kodu hizalı tutmak için adım adım iş akışı

Her ihracı küçük bir sürüm gibi ele alın: yeniden üretin, doğrulayın, yalnızca güvenli olanları yeniden uygulayın, sonra net bir kayıtla kilitleyin. Bu, görsel modeli kaynak doğrusu olarak tutarken kontrollü özel çalışmaya izin verir.

İyi işleyen bir iş akışı:

• En son modelden yeniden üretin: görsel modelin güncel olduğundan emin olun (veri şeması, iş mantığı, UI). Tam olarak o sürümden yeniden üretin ve ihraç edin.
• Temiz bir build ve hızlı bir smoke testi yapın: temiz bir durumdan build edin ve temel "başlıyor mu" kontrolünü çalıştırın. Backend için bir health endpoint'ine istek, web için ana ekranı yükleme gibi.
• Özel kodu yalnızca onaylı uzantı noktaları üzerinden yeniden uygulayın: üretilen dosyaları yeniden kopyalamaktan kaçının. Özel davranışı ayrı bir modüle, wrapper'a veya yeniden üretimi atlatan bir kancaya koyun.
• Otomatik kontrolleri çalıştırın ve önemli çıktıları karşılaştırın: testleri çalıştırın, sonra önemli olanları karşılaştırın: API sözleşmeleri, veritabanı migration'ları ve önemli ekranların hızlı UI kontrolleri.
• Sürümü etiketleyin ve neyin değiştiğini kaydedin: model değişikliklerini (şema, mantık, UI) özel değişikliklerden (uzantılar, entegrasyonlar, konfigürasyonlar) ayıran kısa bir not yazın.

Yeniden üretmeden sonra bir şey bozulursa, mümkün olan her durumda önce modeli düzeltin. Model gereksinimi ifade edemiyorsa özel kod seçin ve bu kodu izole tutun ki bir sonraki regen onu silmesin.

Yönetişim kuralları: roller, onaylar ve değişiklik kontrolü

Platformunuz kodu yeniden üretebiliyorsa (AppMaster gibi), yönetişim kaybolan çalışmaları önleyen şeydir. Net sahiplik ve basit bir onay yolu yoksa ekipler en yakın olanı değiştirir ve yeniden üretim tekrarlayan bir sürprize dönüşür.

Birkaç sahibi adlandırın. Bir komiteye gerek yok ama netlik gerek.

• Model sahibi: veri, API'ler ve çekirdek mantık için görsel modelin sahibi.
• Özel kod sahibi: el yazısı uzantıların ve güvenli uzantı sınırlarının sahibi.
• Sürüm sahibi: versiyonlama, yeniden üretim zamanlaması ve prodüksiyona ne gideceğini koordine eden kişi.

Riskli alanlar için incelemeleri zorunlu kılın. Ödeme, mesajlaşma veya dış API'leri etkileyen veya güvenlik (auth, roller, gizli bilgiler, veri erişimi) ile ilgili özel kod, özel kod sahibinin artı bir gözden geçiren tarafından onaylanmalıdır. Bu stil meselesinden çok, geri çevrilmesi zor sürüklenmeleri engelleme meselesidir.

Değişiklik kontrolü için herkesin doldurabileceği küçük bir değişiklik talebi formu kullanın. İnsanların gerçekten kullanacağı kadar hızlı tutun.

• Ne değişti (model, üretilen kod ayarları veya özel uzantı)
• Neden değişti (kullanıcı ihtiyacı veya bir olay)
• Risk (ne bozulabilir, kim etkilenir)
• Geri alma planı (güvenli nasıl geri alınır)
• Nasıl doğrulanır (bir veya iki kontrol)

Acil düzeltmeler için bir kural belirleyin. Eğer bir hotfix doğrudan ihraç edilmiş koda uygulanmak zorundaysa, aynı değişikliği görsel modele yeniden oluşturmak (veya uzantı noktasını yeniden tasarlamak) için sabit bir zaman aralığı içinde planlayın; örneğin 1-3 iş günü. Bu tek kural genellikle istisnanın geçici mi yoksa kalıcı bir çatala mı dönüşeceğini belirler.

Üzerine yazmalara ve sürüklenmeye neden olan yaygın hatalar

Çoğu üzerine yazma problemi makul bir kestirme ile başlar: "Sadece bu dosyayı değiştiririm." AppMaster gibi yeniden üreten bir platformla bu kestirme genellikle yeniden üretme geldiğinde yeniden çalışma olur çünkü yama kaybolur veya çakışır.

Sürüklenmeye yol açan desenler

En yaygın neden, üretilen kodu düzenlemektir çünkü anlık olarak daha hızlı gelir. Testleri geçer ve yayınlanır; ta ki bir sonraki yeniden üretme gelene kadar: yama kaybolur veya yeni çıktı ile çakışır.

Diğer sık görülen sorun, birden fazla kişinin açık sınır olmadan özel kod eklemesidir. Bir ekip geçici bir yardımcıyı üretilen klasör içine koyar, başka bir ekip aynı alana farklı bir yardımcı ekler; artık güvenle yeniden üretim yapamazsınız veya değişiklikleri temizce inceleyemezsiniz.

Sürüklenme ayrıca sürümlerin yeniden üretimi atlamasıyla da olur çünkü riskli hissettirilir. Sonra görsel model değişir ama prodüksiyon eski bir ihracın kodunu çalıştırır. Birkaç döngü sonra kimse uygulamanın gerçekten ne yaptığını bilemez.

Daha sessiz bir hata, hangi model sürümünün hangi ihracatı ürettiğini kaydetmemektir. Basit bir etiket veya sürüm notu olmadan "Bu API davranışı modelden mi yoksa özel yamadan mı geliyor?" sorusuna cevap veremezsiniz.

Hızlı bir örnek

Bir geliştirici eksik bir doğrulama kuralı fark eder ve boş değerleri engellemek için üretilen Go handler'ını doğrudan düzenler. Testleri geçer ve dağıtılır. İki hafta sonra ekip bir AppMaster İş Süreci günceller ve tekrar ihraç eder. Handler yeniden üretilir, doğrulama gider ve hata geri döner.

Erken uyarı işaretleri:

• Özel commit'lerin üretilen dizinlerin içine düşmesi
• Uzantıların nerede yaşadığına dair yazılı bir kuralın olmaması
• "Bu sürümü yeniden üretemiyoruz" ifadesinin normal hale gelmesi
• Sürüm notlarında kullanılan model sürümünün belirtilmemesi
• Sadece kodda var olan düzeltmeler

Sürüklenmeyi erken yakalayan kalite kontrolleri

Her yeniden üretimi küçük bir sürüm gibi ele alın. Sadece uygulamanın çalışıp çalışmadığını kontrol etmiyorsunuz. Görsel modelin (örneğin AppMaster Data Designer ve Business Process Editor) repoyu dağıtan kodla eşleşip eşleşmediğini de kontrol ediyorsunuz.

Gerçek kullanıcı davranışını taklit eden minimal bir test paketiyle başlayın. Küçük tutun ki her değişiklikte çalışsın, ama para kazandıran veya destek biletlerine neden olan akışları kapsasın. İç kullanım için bu: giriş yap, bir kayıt oluştur, onayla ve raporda gör şeklinde olabilir.

Tekrar edilebilir birkaç odaklı kontrol:

• En önemli 3-5 kullanıcı akışı için smoke testleri (web ve mobil varsa her ikisi)
• Önemli API'ler için sözleşme kontrolleri (istek/yanıt şekli) ve Stripe veya Telegram gibi kritik entegrasyonlar
• İhraç sonrası diff incelemesi; üretken alanlar değil, özel klasörlere odaklanın
• Geri alma tatbikatı: en son bilinen iyi yapı hızlıca yeniden dağıtılabiliyor mu?
• Versiyon kaydı: model sürümü, ihraç tarihi ve dağıtılan commit etiketi

Sözleşme kontrolleri "UI'da iyi görünüyor" problemlerini yakalar. Örnek: yeniden üretilen bir uç nokta hala mevcut ama bir alan tipi integer'dan string'e değişmiş, downstream faturalama çağrısını kırar.

Diff incelemesi için basit bir kural koyun: dosya üretilen bir dizindeyse, elle düzenlemeyeceksiniz. İnceleyenler gürültülü değişiklikleri göz ardı edip sahip olduğunuz (custom modüller, adaptörler, entegrasyon sarmalayıcıları) öğelere odaklanmalı.

Gerekmeden önce bir geri alma planı yazın. Yeniden üretim kırıcı bir değişiklik getirirse, kim geri almayı onaylayabilir, son stabil artefakt nerede, hangi model sürümü onu üretti bilmelisiniz.

Örnek: yeniden üretimde kaybetmeden özel entegrasyon eklemek

Diyelim ekibiniz AppMaster'da bir müşteri portalı oluşturdu ama yerleşik modüller kapsamayan özel bir mesajlaşma entegrasyonu (örneğin, niş bir SMS sağlayıcısı) gerekiyor. Sağlayıcı SDK'sını eklemek ve birkaç köşe durumunu ele almak için kaynak kodu ihraç edersiniz.

Sonrasında acı vermemesi için kural basittir: veri, API uç noktaları ve çekirdek akış için görsel modeli kaynak doğrusu olarak tutun. Özel sağlayıcı kodunu, üretilen kodun çağıracağı ama onun tarafından sahiplenilmeyen bir adaptör katmanına koyun.

Temiz bir ayırım şu şekilde görünür:

• Görsel model (AppMaster): veritabanı alanları, API uç noktaları, kimlik doğrulama kuralları ve mesaj gönderme zamanını belirleyen iş süreci
• Adaptör katmanı (el yazısı): sağlayıcı istemcisi, istek imzalama, tekrar denemeler ve sağlayıcı hatalarını küçük, stabil bir uygulama hataları kümesine eşleme
• İnce sınır: iş sürecinin tetiklediği SendMessage(to, text, metadata) gibi tek bir arayüz

Hafta içi, yeniden üretim sıkıcı hale gelir; amaç budur. Pazartesi ürün değişikliği yeni bir mesaj türü ve PostgreSQL'de yeni bir alan ekler. AppMaster modelini güncellersiniz ve yeniden üretirsiniz. Üretilen backend değişir ama adaptör katmanı değişmez. Eğer arayüz yeni bir parametreye ihtiyaç duyarsa, bir defa değiştirirsiniz ve sonra anlaşılmış sınırdaki tek çağrı noktasını güncellersiniz.

İncelemeler ve testler kabile bilgisina güvenmemenizi sağlar. Minimum olarak iyi olanlar:

• Kimsenin üretilen klasörleri doğrudan düzenlemediğini kontrol eden bir kural
• Adaptör için birim testleri (mutlu yol, sağlayıcı zaman aşımı, geçersiz numara)
• Yeniden üretim sonrası çalışan bir entegrasyon testi ve mesajın gönderildiğini doğrulayan bir test

Bir sonraki kişi için kısa bir entegrasyon kartı yazın: adaptör ne yapar, nerede durur, kimlik bilgileri nasıl döndürülür, testleri nasıl çalıştırılır ve görsel model yeni alanlar eklediğinde ne değiştirilmeli.

Sonraki adımlar: pratik bir uygulama planı (hafif bir araç seçimi notuyla)

Küçük başlayın ve yazılı hale getirin. Bir sayfalık bir politika yeterlidir; repo içinde neyin değişmesine izin verildiğini ve neyin görsel modelde değiştirilmesi gerektiğini cevaplarsa yeter.

Sonra süreci bir gerçek özellik üzerinde pilotlayın. Değerli ama sınırlı bir şey seçin: bir webhook eklemek, küçük bir admin ekranı veya yeni bir onay adımı gibi.

Pratik uygulama planı:

• Politikayı ve sınır diyagramını yazın, repo README'sinin yanına koyun.
• Bir pilot özellik seçin ve uçtan uca çalıştırın: model değişikliği, ihraç, inceleme, dağıtım.
• Belirli aralıklarla (aylık iyi çalışır) kasıtlı yeniden üretim tatbikatı planlayın; yeniden üretin ve önemli hiçbir şeyin üzerine yazılmadığını doğrulayın.
• Basit bir değişiklik kapısı ekleyin: görsel model değişikliği referanslanmamışsa merge yok (ticket, not veya commit mesajı ile).
• İki başarılı tatbikattan sonra aynı kuralları bir sonraki ekibe ve uygulamaya uygulayın.

Araç seçimi notu: AppMaster kullanıyorsanız, veri, API'ler ve iş mantığı için görsel modeli varsayılan yer olarak kabul edin. İhraç edilmiş kodu dağıtım ihtiyaçları (kendi bulutunuz, politika gereksinimleriniz) veya açıkça ayrılmış alanlarda yaşayan kontrollü uzantılar için kullanın.

Eğer appmaster.io üzerinde AppMaster ile çalışıyorsanız, küçük bir no-code proje üzerinde pratik yapmak iyi bir alışkanlıktır: çekirdek uygulama mantığını görsel editörlerde oluşturun, ihraç edin, yeniden üretin ve sınırlarınızın korunduğunu kanıtlayın; sonra daha büyük sistemlere ölçekleyin.