No-code uygulamalar için sürüm yönetimi: pratik bir dallanma ve ortam düzeni, geri alma planlaması ve gereksinimler değiştiğinde hızla yapılacak regresyon kontrolleri.
Bir platform model ve görsel mantıktan uygulamanızı yeniden ürettiğinde, bir sürüm "küçük bir değişikliği göndermek"ten çok "evi yeniden inşa etmek" gibi gelebilir. Bu, kodu temiz tutmak açısından iyidir, ama elle yazılmış kodla edinilen birçok alışkanlığı bozar.
Yeniden üretilen kodla, birkaç dosyayı yamalamazsınız. Veri modelini, iş akışını veya ekranı değiştirirsiniz ve platform uygulamanın yeni bir sürümünü üretir. AppMaster'da backend, web ve mobil aynı değişiklik kümesinden güncellenebilir. Avantajı birikmiş karmaşa olmamasıdır. Dezavantajı ise küçük düzenlemelerin beklediğinizden daha geniş etkileri olabilmesidir.
Ağrı genellikle şu şekillerde ortaya çıkar:
"Güvenli" hiçbir şeyin asla ters gitmeyeceği anlamına gelmez. Anlamı, sürümlerin öngörülebilir olması, sorunların kullanıcılar bildirmeden önce ortaya çıkması ve geri almanın hızlı ve sıradan olmasıdır. Buna, net terfi kuralları (dev → staging → prod), stres altında uygulanabilecek bir geri alma planı ve gerçekten değişenlere bağlı regresyon kontrolleri ile ulaşılır.
Bu yazı, sık sık dağıtım yapan solo geliştiriciler ve küçük ekipler için. Haftalık veya günlük sürüm yapıyorsanız, platformun tek tıklamayla her şeyi yeniden üretebilse bile değişikliklerin sıradan hissettireceği bir rutine ihtiyacınız var.
No-code için bile en güvenli kurulum en basit olanıdır: net görevleri olan üç ortam.
Dev geliştirdiğiniz ve kasıtlı olarak kırdığınız yerdir. AppMaster'da veri modelini düzenlediğiniz, iş süreçlerini ayarladığınız ve UI üzerinde hızlı iterasyon yaptığınız yerdir. Dev hız içindir, stabilite için değildir.
Staging bir provadır. Üretime benzer görünmeli ve davranmalı, ama gerçek müşterilerin ona bağlı olmadığı bir ortam olmalı. Staging, yeniden üretilmiş bir derlemenin uçtan uca çalıştığını doğruladığınız yerdir; kimlik doğrulama, Stripe ödemeleri, e-posta/SMS veya Telegram mesajlaşması gibi entegrasyonları içerir.
Prod gerçek kullanıcıların ve gerçek verinin bulunduğu yerdir. Production değişiklikleri tekrarlanabilir ve minimal olmalıdır.
Ekipleri hizada tutacak pratik bir ayrım:
Değişiklikleri takvime değil güvene göre terfi ettirin. Özelliğin tümüyle test edilebilir olduğunda (ekranlar, mantık, izinler ve veri değişiklikleri birlikte) dev'den staging'e taşıyın. Staging'den prod'a yalnızca ana akışları iki kez sürdürüp sürpriz olmadığından emin olduktan sonra taşıyın: temiz bir dağıtımda bir kez ve küçük bir yapılandırma değişikliğinden sonra bir kez.
Basit isimlendirme gerilim anlarında karışıklığı azaltır:
Staging'i “neredeyse tamam” işlerinin park yeri olarak değil, üretim davranışının bir kopyası olarak değerlendirin.
Dallanma kod üreteciyi korumakla ilgili değildir. Prod davranışını korumakla ilgilidir.
Üretimdeki ile eşleşen ve her zaman yayınlanabilir durumda olan tek bir ana dal ile başlayın. AppMaster terimleriyle bu ana dal, kullanıcıların güvendiği mevcut Data Designer şemasını, iş süreçlerini ve UI durumunu temsil eder.
Pratik bir kurulum:
Feature dallarını küçük ve kısa tutun. Bir değişiklik veri, mantık ve UI'yi etkiliyorsa, her biri uygulamayı çalışır durumda bırakan iki veya üç merge'e bölün (özellik bir toggle arkasında saklı olsa bile).
Release dalını sadece aynı hafta birden fazla ekibin gönderdiği durumlarda ya da stabilizasyon zamanı gerektiğinde kullanın. Aksi halde sık sık main'e merge edin ki dallar sapmasın.
Birkaç merge kuralı "yeniden üretim sürprizlerini" önler:
Örnek: bir onay adımı ekliyorsanız, önce iş akışı mantığını merge edin ve eski yol hâlâ çalışsın. Sonra UI ve izinleri merge edin. Daha küçük adımlar regresyonları bulmayı kolaylaştırır.
Tutarlılık her şeyi klonlamak demek değildir. Doğru şeyleri aynı tutmaktır.
Uygulama tanımınız (veri modeli, mantık, UI) güvenle ilerlemeli, her ortam kendi ayarlarını saklamalıdır. Pratikte dev, staging ve prod aynı üretilen kodu ve aynı şema kurallarını kullanmalı, ancak farklı ortam değerlerine sahip olmalıdır: domainler, üçüncü taraf uç noktaları, oran limitleri ve özellik toggle'ları.
Gizli anahtarlar için bir planınız olmalı. API anahtarları, OAuth istemci sırları ve webhook'ları ortam sahipliğinde tutun, proje sahipliğinde değil. Basit bir kural işe yarar: geliştiriciler dev gizli anahtarlarını okuyabilir, daha küçük bir grup staging gizli anahtarlarını okuyabilir, neredeyse hiç kimse prod gizli anahtarlarını okuyamaz. Anahtarları belirli aralıklarla yenileyin ve bir prod anahtarı bir dev aracına düşerse hemen rotasyon yapın.
Staging, hataları yakalayan bakımlardan prod ile “aynı” olmalı, risk oluşturan açılardan değil:
Prod verisini staging'e kopyalamaktan kaçının, zorunlu değilse. Yapmanız gerekirse kişisel verileri maskeleyin ve kopyayı kısa ömürlü tutun.
Örnek: İş Sürecine yeni bir onay adımı ekliyorsunuz. Staging'de test Stripe hesabı ve test Telegram kanalı kullanın, artı en büyük gerçek sipariyinizi taklit eden sentetik siparişler. Bu şekilde izin ve eksik koşullar gibi hataları yakalarsınız, müşterileri riske atmadan.
AppMaster kullanıyorsanız, uygulama tasarımını ortamlar arasında tutarlı tutun ve dağıtım başına sadece ortam ayarlarını ve gizli anahtarları değiştirin. Bu disiplin sürümleri öngörülebilir kılar.
Platformunuz her değişiklikten sonra kodu yeniden ürettiğinde, en güvenli alışkanlık küçük adımlarla ilerlemek ve her adımı doğrulamayı kolaylaştırmaktır.
Değişikliği küçük, test edilebilir bir gereksinim olarak yazın. Teknik olmayan bir ekip üyesinin doğrulayabileceği bir cümle: "Yöneticiler onay notu ekleyebilecek ve istek yönetici onaylayana kadar Beklemede kalacak." 2–3 kontrol ekleyin (kim görebilir, onay/red durumunda ne olur).
Dev'de inşa edin ve sık sık yeniden üretin. AppMaster'da bu genelde Data Designer'ı (veri değişiyorsa) güncellemek, İş Süreci mantığını ayarlamak, sonra yeniden üreterek uygulamayı çalıştırmak demektir. Değişiklikleri sıkı tutun ki kırılmanın nedeni kolayca görülsün.
Aynı sürümü staging'e dağıtın ve tam kontroller yapın. Staging mümkün olduğunca prod ayarlarına uymalı. Entegrasyonları staging-güvenli hesaplarla doğrulayın.
Bir sürüm adayı (RC) oluşturun ve kısa bir süre freeze uygulayın. Bir derlemeyi RC olarak seçin. Test sonuçları geçerli kalması için kısa bir süre (30–60 dakika bile) yeni merge'leri durdurun. Bir şey düzeltilmesi gerekirse sadece o konuda düzeltme yapın ve yeni bir RC kesin.
Prod'a dağıtın, sonra ana kullanıcı akışlarını doğrulayın. Yayından hemen sonra para kazandıran veya operasyonu döndüren 3–5 akışı hızlıca kontrol edin (giriş, kayıt oluşturma, onay, ihracat/rapor, bildirimler).
Staging'de bir şey belirsizse durun. Sakin bir gecikme aceleyle geri almaktan daha ucuzdur.
Yeniden üretilen kodla, “geri alma”nın net bir anlamı olmalı. Önceden karar verin: geri alma şunlardan hangisi mi?
Çoğu gerçek olay her ikisini gerektirir: kod geri alma artı üçüncü taraf bağlantılarını ve toggle'ları son iyi duruma getiren bir konfigürasyon sıfırlaması.
Her ortam için basit bir kayıt tutun (dev, staging, prod): sürüm etiketi, dağıtım zamanı, onaylayan kişi ve ne değişti. AppMaster'da bu, dağıttığınız tam uygulama sürümünü ve kullanılan ortam değişkenleri ile entegrasyon ayarlarını kaydetmek demektir. Stres altında hangi derlemenin stabil olduğunu tahmin etmemelisiniz.
Veritabanı değişiklikleri genelde hızlı geri almayı engeller. Değişiklikleri tersine çevrilebilir ve tersine çevrilemez olarak ayırın. Nullable bir sütun eklemek genelde geri alınabilir. Bir sütunu silmek veya değerlerin anlamını değiştirmek genelde değildir. Riskli değişiklikler için hızlı bir hotfix yolu planlayın ve gerekiyorsa sürümden hemen önce bir yedek noktası alın.
Uygulanabilir bir geri alma planı:
Staging'de uygulama yapın. Sahte bir olayı aylık olarak çalıştırın ki geri alma kas hafızası haline gelsin.
En iyi regresyon kontrolleri kırılabilecek şeylere bağlıdır. Bir forma eklenen yeni alan nadiren her şeyi tekrar test etmeyi gerektirir, ama doğrulamayı, izinleri ve downstream otomasyonları etkileyebilir.
Önce patlama yarıçapını adlandırın: hangi ekranlar, roller, veri tabloları ve entegrasyonlar etkilendi. O yarıçapı kesen yolları ve her zaman çalışması gereken birkaç temel akışı test edin.
Altın yollar her sürümde geçmesi gereken iş akışlarıdır:
Beklenen sonuçları düz bir dille yazın (ne görmelisiniz, ne oluşturulmalı, hangi durum değişmeli). Bu, tekrarlanabilir bitiş tanımınız olur.
Entegrasyonları mini-sistemler gibi ele alın. Bir değişiklikten sonra UI iyi görünse bile her entegrasyon için bir hızlı kontrol çalıştırın. Örneğin: bir Stripe ödemenin tamamlanması, bir e-posta şablonunun doğru render edilmesi, bir Telegram mesajının ulaşması ve bir AI çağrısının kullanılabilir bir yanıt döndürmesi.
Gizli başarısızlıkları yakalayan birkaç veri sağlamlığı kontrolü ekleyin:
AppMaster gibi platformlarda, uygulamalar düzenlendikten sonra yeniden üretilebildiğinden, odaklanmış kontroller yeni derlemenin amaçlanmayan davranış değişiklikleri yapmadığını doğrulamaya yardımcı olur.
Prod'a itmeden önce amaç mükemmellik değildir. Amaç en çok zarar veren hataları yakalamaktır: bozuk giriş, yanlış izinler, başarısız entegrasyonlar ve sessiz arka plan hataları.
Staging'i gerçek bir provaya dönüştürün. AppMaster'da bu genelde staging'e taze bir build ve deploy yapmayı (yarım yamalanmış bir ortam değil) ifade eder, böylece tam olarak ne göndereceğinizi test edersiniz.
Yaklaşık 10 dakikada yapılacak beş kontrol:
Uygulamanız otomasyon kullanıyorsa, bir planlı/asenkron işi tetikleyin ve çoğaltma yapmadan tamamlandığını doğrulayın (iki kayıt, iki mesaj, iki ücret olmamalı).
Herhangi bir kontrol başarısız olursa, sürümü durdurun ve yeniden üretilebilir adımları yazın. Net, tekrarlanabilir bir sorunu düzeltmek umutla göndermekten daha hızlıdır.
Operasyon ekibiniz dahili bir satınalma taleplerini onaylamak için bir araç kullanıyor. Bugün iki adım var: talep sahibi gönderir, yönetici onaylar. Yeni gereksinim: 5.000$ üzerindeki her şey için finans onayı ekle ve finans onaylayınca veya reddedince bildirim gönder.
Bunu kapsayıcı bir değişiklik olarak ele alın. Prod'ta stabil olan ana dalınızdan kısa ömürlü bir feature dalı oluşturun. Önce dev'de inşa edin. AppMaster'da bu genelde Data Designer'ı güncellemek (yeni durum veya alan), Business Process Editor'da mantık eklemek, sonra web/mobil UI'yi yeni adımı gösterecek şekilde güncellemek demektir.
Dev'de çalışıyorsa, aynı dalı staging'e terfi ettirin (aynı konfigürasyon stili, farklı veriler). Bilerek kırmaya çalışın, özellikle izinler ve uç durumlar etrafında.
Staging'de test edin:
Sakin bir pencerede prod'a dağıtın. Finans onayları çalışmaz veya bildirimler yanlış gönderilirse yeniden dağıtılmak üzere önceki prod sürümünü hazır tutun. Veri değişikliği eklediyseniz, baştan karar verin: geri alma "eski sürümü yeniden dağıtmak" mı yoksa "eski sürüm artı küçük bir veri düzeltmesi" mi demek olacak.
Değişikliği kısa birkaç satırla belgeleyin: ne eklediniz, staging'de neyi test ettiniz, sürüm etiketi/versiyon ve en büyük risk (genelde izinler veya bildirimler). Bir dahaki gereksinim kayması daha az tartışma ve daha hızlı ilerleme sağlar.
Ağır sürümler nadiren tek bir büyük hatadan gelir. Genelde değişikliklerin ne olduğunu, nerede olduğunu ve nasıl geri alınacağını görmekte zorlanmaktan kaynaklanan kestirmeler yüzündendir.
Yaygın tuzaklardan biri "hazır olana kadar" saklanan uzun ömürlü dallardır. Sapma oluşur. İnsanlar dev'de düzeltir, staging'i değiştirir ve prod'ta hotfix yapar. Haftalar sonra kim gerçek sürümün hangisi olduğunu söyleyemez ve merge yapmak riskli bir tahmine dönüşür. AppMaster gibi platformlarda kısa ömürlü dallar ve sık merge'ler değişiklikleri anlaşılır tutar.
Bir diğer sürüm katili "sadece küçük bir değişiklik" bahanesiyle staging'i atlamaktır. Küçük değişiklikler sıklıkla paylaşılan mantığı etkiler: doğrulama kuralları, onay adımları, ödeme callback'leri. UI değişikliği küçük görünür, ama yan etkiler prod'ta ortaya çıkar.
Prod'ta yapılan manuel ayarlar da pahalıdır. Birisi "bir kez" prod'ta ortam değişkeni, feature flag, ödeme anahtarı veya webhook değiştirirse tekrarlanabilirliği kaybedersiniz. Bir sonraki sürüm farklı davranır ve nedenini kimse bilmez. Her prod ayar değişikliğini bir sürüm parçası olarak kaydedin ve her seferinde aynı şekilde uygulayın.
Geri alma hataları en çok zarar verir. Ekipler uygulama sürümünü geri alır ama verinin ileriye hareket ettiğini unutur. Sürümünüze şema değişikliği veya yeni zorunlu alanlar eklediyseniz, eski kod yeni veriye karşı başarısız olabilir.
Birkaç alışkanlık bunun çoğunu önler:
"Bitti" sinyali yoksa sürümler asla gerçekten bitmez. Sadece bir sonraki acil duruma kayarlar.
Sürüm stresi, sürüm gününde verilen kararlardan gelir. Çözüm bir kez karar verip yazıya geçirmek ve tekrarlamaktır.
Dallanma kurallarınızı tek sayfaya, herkesin sizin yanınızda olmadığında bile izleyebileceği basit dille koyun. Bir değişiklik için neyin "bitti" sayılacağını tanımlayın (koşullar çalıştırıldı, onay, sürüm adayı ne sayılır).
Sıkı bir yapı isterseniz basit kurallar şunlar olabilir:
Ortamları amaçlı olarak farklı hissettirin. Dev hızlı değişimler içindir, staging sürümü kanıtlamak içindir, prod müşterilerdir. Prod erişimini kilitleyin ve staging için bir sürüm kapısı sahibi atayın.
AppMaster üzerinde inşa ediyorsanız, platformun "temiz kaynak kodu yeniden üret" yaklaşımı disiplinli ortamlar ve hızlı altın yol kontrolleri ile eşleştirildiğinde en rahat olur. Araç değerlendiren ekipler için AppMaster (appmaster.io), backend, web ve native mobil dahil tam uygulamalar için tasarlanmıştır; bu tarz bir sürüm rutini özellikle faydalıdır.
Daha küçük gönderin ve daha sık gönderin. Bir ritim seçin (haftalık veya ayda iki kez) ve bunu normal iş kabul edin. Küçük sürümler incelemeleri hızlandırır, geri almayı basitleştirir ve "umarım işe yarar" anlarını nadir kılar.
Do I really need dev, staging, and prod for a no-code app?Use three environments: dev for fast changes, staging for a production-like rehearsal, and prod for real users. This keeps risk contained while still letting you ship often.
Why do releases feel riskier when the platform regenerates the app?Because regeneration can rebuild more than you intended. A small change to a shared field, workflow, or permission can ripple across screens and roles, so you need a repeatable way to catch surprises before users do.
What should staging include to actually be useful?Treat staging as a rehearsal that mirrors production behavior. Keep the same schema rules and core integrations, but use staging-safe accounts and separate secrets so you can test end to end without risking real money or real users.
What branching strategy works best with regenerated code?Start with one mainline branch that matches production and is always releasable, plus short-lived feature branches for single changes. Add a release branch only when you need a brief stabilization window, and keep hotfix branches minimal and urgent.
How do I avoid “one small change broke everything” merges?Split it into smaller merges that each leave the app working. For example, merge workflow logic first (keeping the old path working), then UI and permissions, then any stricter validation, so regressions are easier to spot and fix.
How should I handle API keys and secrets across environments?Store them as environment-owned and limit who can read them, especially in production. Use separate keys per environment, rotate them on a schedule, and rotate immediately if a production key ever ends up in a dev tool.
What is a release candidate, and when should I freeze changes?Pick one tested build as the RC and pause new merges briefly so test results stay valid. If you find an issue, fix only that issue and cut a new RC, instead of piling on extra changes mid-test.
What does rollback mean for a regenerated app?Decide in advance whether rollback means redeploying the previous build, restoring the previous configuration, or both. In most incidents you need both, plus a quick verification of the 3–5 critical user flows right after rollback.
How do database changes affect rollback?Assume schema and validation changes can block rollback. Prefer reversible changes first (like adding nullable fields), and for risky changes plan a forward-fix path and take a backup right before release if you might need to restore data.
How do I run regression checks without testing everything?Run a short set of golden paths every release, then test only what’s in the blast radius of your change (screens, roles, tables, integrations). Separately smoke-test each integration once so silent failures show up early.
What common mistakes cause painful releases?Keep branches short and merge frequently to reduce drift; don’t skip staging even for tiny changes; treat production settings as part of the release; plan rollbacks that include data compatibility; and define a clear “done” signal for prod so releases actually finish.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
