Branches

Lakebase'de dallanma, Git'te kodunuzu dallama gibi veri ortamınızı güvenli bir şekilde sürümlemenize, test etmenizi ve geliştirmenizi sağlar. Üretim iş yüklerini etkilemeden şema değişikliklerini geliştirme, deneme veya test etme için anında yalıtılmış, tam işlevsel dallar oluşturabilirsiniz.

Varsayılan olarak, yeni bir proje oluşturduğunuzda Lakebase tek production bir dal oluşturur. Bu, uygulamanızın üretim verilerini barındıracak varsayılan dalınızdır.

İş akışınıza uyacak ek dallar oluşturabilirsiniz. Örneğin, derleme ve test için bir development dal, üretim öncesi test için bir staging dal veya tam yalıtım için geliştirici başına dallar oluşturun. Her dal bağımsız çalışır, bu yüzden bir alt daldaki değişiklikler ana dalı etkilemez. Dal sıfırlama işlemi ile ana dalından herhangi bir alt dalı yenileyerek veri tohumlama veya yıkım betiklerine gerek kalmadan en son şemayı ve verileri alabilirsiniz.

Dallar nasıl çalışır?

Ebeveyn-çocuk ilişkileri

Her dalın (kök dal hariç) bir üst öğesi vardır. Bu bir hiyerarşi oluşturur:

production (root branch)
├── staging (child of production)
│   └── feature-test (child of staging)
└── development (child of production)
    └── bugfix-branch (child of development)

Bu hiyerarşi size önemli bir yalıtım sağlar: Alt daldaki değişiklikler ana dalı etkilemez ve ana daldaki değişiklikler alt dallarda otomatik olarak görünmez. Bu izolasyon, Postgres rol durumu ve veritabanlarını da kapsar: bir dalda oluşturulan roller ve veritabanları, uygulanan GRANT'ler ve REVOKE'lar ve değiştirilen rol nitelikleri diğer dallar üzerinde hiçbir etkiye sahip değildir. Ana daldan güncellenmiş verilere ihtiyacınız olduğunda alt dalı sıfırlayabilirsiniz. Ayrıca, üst öğe geçmişinin herhangi bir noktasından dallar oluşturabilirsiniz. Bu, belirli bir zaman noktasına geri yükleme, geçmiş verilere karşı testler yapmak veya uyumluluk senaryoları için kullanışlıdır.

Bir dal oluşturduğunuzda, dalı geçerli verilerden mi yoksa belirli bir zaman noktasından mı başlatabileceğinizi seçersiniz. Her seçenekle ilgili adım adım yönergeler ve ayrıntılar için bkz. Dal oluşturma.

Yazma üzerine kopyalama depolama alanı

Lakebase, ebeveyn-çocuk dallanmasını verimli hale getirmek için kopyala-yaz teknolojisini kullanır. Yeni bir dal oluşturduğunuzda, hem şemayı hem de verileri üst dalından devralır, ancak temel depolama alanını işaretçiler aracılığıyla aynı verileri paylaşır. Yalnızca verileri değiştirdiğinizde Lakebase yeni veriler yazar. Bu, şu anlama gelir:

  • Dallarınız anında görünür; veritabanınızın boyutunun dal oluşturma süresi üzerinde hiçbir etkisi yoktur
  • Dal oluşturmanın üretim iş yükünüz üzerinde performans etkisi yoktur

Copy-on-write, şubelerin nasıl saklanacağını belirler, ancak bir şubenin nasıl faturalandırıldığı süresinin dolup dolmadığına bağlıdır. Dallanmanın kaynak tüketimini nasıl etkilediğine bakınız.

production branch                child branch (at creation)
┌─────────────────┐       ┌─────────────────┐
│  [Data A]       │◄──────│  → Data A       │  (shared)
│  [Data B]       │◄──────│  → Data B       │  (shared)
│  [Data C]       │◄──────│  → Data C       │  (shared)
└─────────────────┘       └─────────────────┘

After modifying data in child branch:
┌─────────────────┐       ┌─────────────────┐
│  [Data A]       │◄──────│  → Data A       │  (shared)
│  [Data B]       │       │  [Data B']      │  (changed)
│  [Data C]       │◄──────│  → Data C       │  (shared)
└─────────────────┘       └─────────────────┘
                          Only changed data is stored separately

Dallarla çalışma

Dal sıfırlama

Anında dal sıfırlama, bir alt dalı ana dalının geçerli durumuyla eşleşecek şekilde güncelleştirir. Bu, geliştirme veya hazırlama dalınızı üst öğesinden alınan en son verilerle yenilemek istediğinizde kullanışlıdır. İşlem, yazma üzerine kopyalama teknolojisi kullanılarak anında tamamlar ve bağlantı bilgileriniz aynı kalır.

Dal sıfırlama yalnızca bir yönde çalışır (üst → alt). Değişiklikleri alt sistemden üst sisteme taşımak için, şema değişikliklerini taşımak üzere standart geçiş araçlarınızı kullanın. Ayrıntılı adımlar ve senaryolar için Bir dalı sıfırlama başlığına bakın.

Anlık Kurtarma

Geri yükleme pencerenizin belirli bir noktasından bir dal oluşturabilirsiniz. Bu, yanlışlıkla silme, geçmiş sorunları araştırma veya denetim ve uyumluluk amacıyla geçmiş verilere erişme gibi veri hatalarından kurtarmak için kullanışlıdır. Örneğin, kritik bir tablo dün saat 10:23'te silindiyse, eksik verileri geri almak için 10:22 olarak ayarlanmış bir dal oluşturabilirsiniz. Benzer şekilde, finansal mutabakatlar, mevzuat denetimleri veya adli analiz için belirli tarihlerde veritabanı durumunuzu yansıtan dallar oluşturabilirsiniz. Dal sıfırlamadan (mevcut bir dalı yerinde güncelleştirir) farklı olarak, belirli bir noktaya kurtarma, özgün dalınızı değiştirmeden ve çalışır durumda bırakırken geçmiş verilerden yeni bir kök dal oluşturur. Ayrıntılar için bkz. Belirli bir zaman noktasına geri yükleme .

Özel dal türleri

Varsayılan dal

Her Lakebase projesi, adlı productionbir varsayılan dalla oluşturulur, ancak herhangi bir dalı varsayılan olarak belirleyebilirsiniz. Varsayılan dal eşzamanlı olarak etkin işlem sınırından muaf tutulur ve her zaman kullanılabilir durumda kalmasını sağlar.

Korumalı dallar

Korumalı dalların yanlışlıkla yapılan değişiklikleri önlemeye yönelik korumaları vardır. Üst öğelerinde silinemez veya yeniden başlatılamazlar ve etkin olmama nedeniyle otomatik arşivlemeden muaf tutulurlar. Korumalı dallar, mevcut oldukları sırada proje silme işlemini de engelleyerek kritik altyapıyı yanlışlıkla kaldıramamanızı sağlar. Ayrıca Lakebase, depolama önbelleğindeki korumalı dalların verilerini önceliklendirir ve korumalı dalların performansını diğer dallara göre önceliklendirir. Her proje bir korumalı dalı destekler. Üretim gibi kritik veriler için korumalı dalları kullanın. Ayrıntılar için bkz . Korumalı dallar .

Dallanma kaynak tüketimini nasıl etkiler?

branch'lerle hesaplama ve depolama için ayrı ayrı ödeme yaparsınız.

İşlem: Her dal, bağımsız olarak ölçeklendirebileceğiniz kendi işlemine sahiptir. Yalnızca etkin işlem saatleri için ödeme alırsınız. İşlemler boştayken sıfıra ölçeklendirilir. Bu, zaman zaman kullandığınız bir geliştirme dalı, 7/24 ayrılmış bir geliştirme sunucusu çalıştırmaya kıyasla çok daha düşük maliyetli olduğu anlamına gelir.

Depolama: Bir şubenin depolama için nasıl faturalandırıldığı, son kullanma süresi olup olmadığına bağlıdır:

  • Süresi dolan bir dal, yalnızca üzerinde değişen veriler için faturalandırılır. Copy-on-write aracıyla, ebeveyninin değişmemiş verilerini paylaşır. Örneğin, 100GB veritabanının süresi dolmakta olan bir dalında 1GB veriyi değiştirirseniz, tam 100GB kopya için değil, yaklaşık 1GB depolama için ödeme yaparsınız.
  • Süresi sonu olmayan kalıcı bir şube, verileri ebeveyninden sadece biraz farklı olsa bile, bağımsız bir veritabanı gibi tam veri boyutuna göre faturalandırılır.

Warning

Bir dalı kalıcı yapmak, sadece üzerindeki değişen veri için değil, tam veri boyutu için ödeme yapmanız anlamına gelir. Bir dalın hiç süresi dolmayacak şekilde ayarlanması her zaman bilinçli bir seçimdir: dalı oluştururken Otomatik silme için Asla seçersiniz veya mevcut bir daldan son kullanma süresini kaldırırsınız. Yalnızca kısa ömürlü bir kopyaya ihtiyacınız varsa, dalın yalnızca üzerinde yapılan değişiklikler için ücretlendirilmesi amacıyla bir sona erme tarihi belirleyin. Bkz. Dalın süresinin dolması.

Dal stratejileri

Ekiplerin dallarını düzenlemenin bazı yaygın yolları şunlardır:

Basit (bireyler ve küçük ekipler)

Varsayılan dalınızı tek bir geliştirme dalı ile kullanın:

production
└── development

Dalınız development , yeni özellikleri güvenli bir şekilde oluşturduğunuz yerdir. Üretim dalınız için herhangi bir risk olmadan şema değişiklikleri yapabilir, test verileri ekleyebilir ve denemeler yapabilirsiniz. Hazır olduğunuzda, test edilen şema geçişlerinizi production üzerinde çalıştırın (geçiş aracınızı kullanarak) ve ardından yeni verilerle sonraki özelliği başlatmak için sıfırlayın development .

Aşamalı Hazırlık ile

Üretim öncesi test için bir hazırlama dalı ekleyin:

production
├── staging
└── development

Üretim öncesi teste ihtiyacınız varsa, üretim dalınızın verilerini yansıtan bir staging dal koruyun. Uygulamanızı oraya dağıtın, gerçekçi verilere karşı tümleştirme ve performans testleri çalıştırın ve canlı yayına geçmeden önce güven kazanın. staging'ı düzenli aralıklarla production'den sıfırlayarak test verilerinizi yenileyin.

Geliştirici başına dallar

Her geliştirici tam yalıtımla çalışır:

production
└── development
    ├── dev-alice
    ├── dev-bob
    └── dev-charlie

Bu düzen, geliştiricilerin birbirlerinin çalışmalarına müdahale etmesini engeller ve herkesin şema değişikliklerini bağımsız olarak test etmesini sağlar. Her geliştirici, başkalarını etkilemeden kendi şema değişiklikleri ve veri değişiklikleriyle denemeler yapabilir, ardından hazır olduğunda paylaşılan development veya production dala test edilmiş geçişler uygulayabilir.

Note

staging ve geliştirici başına kalıpları uzun ömürlü dallar kullanır. Süre sonu olmayan bir dal, tam veri boyutu üzerinden faturalandırılır. Dallanmanın kaynak tüketimini nasıl etkilediğine bakınız.

Ek kaynaklar

  • Last updated on