Sürüme alınan hizmet güncelleştirmeleri aracılığıyla kapalı kalma süresini ortadan kaldırma

Geçmişte yöneticilerin şirket içi yazılımları güncelleştirmek ve yükseltmek için sunucuyu çevrimdışına alması gerekiyordu. Ancak kapalı kalma süresi, genel 24×7 hizmetleri için tam bir başlangıç olmayan hizmettir. Birçok modern bulut hizmeti, kullanıcıların işlerini çalıştırması için kritik bir bağımlılıktır. Sistemi çökertmek için hiçbir zaman iyi bir zaman yoktur, bu nedenle bir ekip önemli güvenlik ve özellik güncelleştirmelerini yüklerken nasıl sürekli hizmet sağlayabilir?

Sürümlenmiş güncelleştirmeler kullanılarak, müşteriler bunları etkin bir şekilde kullanırken bu kritik hizmetler bir sürümden diğerine sorunsuz bir şekilde geçirilebilir. Tüm güncelleştirmeler zor değildir. Ön uç düzenlerini veya stillerini güncelleştirmek kolaydır. Özelliklerde yapılan değişiklikler karmaşık olabilir, ancak geçiş risklerini azaltmak için iyi bilinen uygulamalar vardır. Ancak, veri katmanından kaynaklanan değişiklikler özel dikkate alınması gereken yeni bir zorluk sınıfına neden olabilir.

Katmanları ayrı olarak güncelleştirme

Birden çok veri merkezinde dağıtılmış bir çevrimiçi hizmet ve ayrı veri depolaması ile her şey aynı anda değiştirilemez. Tipik hizmet, büyük olasılıkla birbirinden bağımsız olarak sürümlenmiş olan uygulama kodu ve veritabanlarına bölünürse, bu taraflardan birinin sürüm oluşturma işleminin karmaşıklığını emmesi gerekir.

Genellikle, uygulama kodunda sürüm oluşturmanın işlenmesi daha kolaydır. Daha büyük sistemler genellikle veritabanlarında bulunan SQL gibi oldukça eski kodlara sahiptir. Bu SQL'i daha da karmaşık hale getirmesi yerine, uygulama kodunun karmaşıklığı işlemesi gerekir. Özellikle, SQL sürüm oluşturmayı anlayan bir fabrika sınıfları kümesi oluşturabilirsiniz.

Her sprint sırasında, her veritabanı sürümüyle eşleşen her zaman kod olması için bu sürümle yeni bir arabirim oluşturun. Dağıtım sırasında ikili dosyaları kolayca geri alabilirsiniz. Yeni ikili dosyaları dağıttığınızda bir sorun olursa önceki koda geri dönebilirsiniz. İkili dağıtım başarılı olursa veritabanı servisini başlatın.

Peki bu nasıl çalışıyor? Örneğin, ekibinizin şu anda Sprint 123 dağıttığını varsayalım. İkili dosyalar Sprint 123 veritabanı şemasını ve Sprint 122 şemasını anlar. Genel desen, SQL şemasının hem N hem de N-1 sürümleriyle çalışmaktır. İkili dosyalar veritabanını sorgular, hangi şema sürümüyle konuştuklarını belirler ve ardından uygun bağlamayı yükler. Ardından, yeni veri şeması henüz kullanılabilir olmadığında uygulama kodu olayı işler. Yeni sürüm kullanıma sunulduktan sonra, uygulama kodu en son veritabanı sürümü tarafından etkinleştirilen yeni işlevselliği kullanmaya başlayabilir.

Yalnızca veri katmanıyla ileri sarma

Veritabanları yükseltildikten sonra bir sorun oluşursa hizmet ileri sarma durumunda olur. Çevrimiçi veritabanı geçişleri karmaşıktır ve genellikle çok adımlıdır, bu nedenle ileriye doğru ilerlemek genellikle bir sorunu çözmenin en iyi yoludur. Başka bir deyişle yükseltme başarısız olursa geri alma işlemi de başarısız olabilir. Ekibinizin hiç kullanmayı beklemediğini geri alma kodu oluşturma ve test etme çabasına yatırım yapmanın değeri çok azdır.

Dağıtım sırası

Veritabanına sütun kümesi eklemeniz ve bazı verileri dönüştürmeniz gereken bir senaryo düşünün. Bu geçişin kullanıcılar tarafından görülememesi gerekir; bu da tablo kilitlerini mümkün olduğunca önlemek ve sonra algılanabilir olmaması için kilitleri mümkün olan en kısa süre boyunca tutmak anlamına gelir.

İlk olarak verileri işlemek ve büyük olasılıkla sql tetikleyicisi kullanarak verileri eşitlenmiş durumda tutmaktır. Büyük veri geçişleri ve dönüşümleri bazen birden çok sprint'de çeşitli dağıtımlar üzerinde çok adımlı olmalıdır.

Ek veriler veya yeni şema paralel olarak oluşturulduktan sonra, ekip uygulama kodu için dağıtım moduna geçer. Dağıtım modunda, kod veritabanına bir çağrı yaptığında, önce şemada bir kilit alır ve saklı yordamı çalıştırdıktan sonra serbest bırakır. Veritabanı, veritabanına yapılan çağrının verildiği zaman ile saklı yordamın çalıştırıldığı zaman arasında değişemez.

Yükseltme kodu şema yazıcısı işlevi görür ve şemada bir yazıcı kilidi istemektedir. Uygulama kodu, okuyucu kilidi alma önceliğini alır ve yükseltme kodu yazıcı kilidini almaya çalışırken arka planda yer alır. Yazıcı kilidi altında, tablolarda yalnızca az sayıda çok hızlı işleme izin verilir. Ardından kilit serbest bırakılır ve uygulama veritabanının yeni sürümünün kullanımda olduğunu kaydeder ve yeni veritabanı sürümüyle eşleşen arabirimi kullanır.

Veritabanı yükseltmelerinin tümü bir geçiş deseni kullanılarak gerçekleştirilir. Kod ve betik kümesi veritabanının sürümüne bakar ve şemayı eski sürümden yeni sürüme geçirmek için artımlı değişiklikler yapar. Tüm geçişler otomatikleştirilmiştir ve yayın yönetimi hizmeti aracılığıyla dağıtılır.

Web kullanıcı arabirimi de kullanıcıları kesintiye uğratmadan güncelleştirilmelidir. JavaScript dosyalarını, stil sayfalarını veya görüntüleri yükseltirken istemci tarafından yüklenen eski ve yeni sürümleri karıştırmaktan kaçının. Bu, bir kullanıcı tarafından düzenlenen bir alan gibi devam eden çalışmayı kaybedebilecek hatalara yol açabilir. Bu nedenle, bir dağıtımla ilişkili tüm dosyaları ayrı, sürümlenmiş bir klasöre yerleştirerek tüm JavaScript, CSS ve görüntü dosyalarını sürümlendirmelisiniz. Web kullanıcı arabirimi uygulama katmanına geri çağrı yaptığında, belirtilen sürüme sahip varlıklar yüklenir. Yalnızca bir kullanıcı eylemi tam sayfa yenilemeyle sonuçlandığında yeni web kullanıcı arabirimi tarayıcıya yüklenir. Kullanıcının deneyimi yükseltme tarafından kesintiye uğramaz.

Sonraki adımlar

Microsoft, onlarca yıldır dünyanın en büyük yazılım geliştirme şirketlerinden biri olmuştur. Microsoft'un DevOps ile güvenilir sistemleri nasıl çalıştıracağınızı öğrenin.