Arka fon

Sıfır kesinti süresi dağıtımını uygulamak isteyen bir ekipte çalışıyorum. Bunu başarmak için mavi / yeşil bir dağıtım stratejisi kullanmayı planlıyoruz. Araştırma yaparken anladığım şeylerden biri de veritabanı değişiklik yapmanın ne kadar karmaşık olduğu. Bir sütunu yeniden adlandırmak gibi basit bir işlem tamamlanana kadar 3 tam serbest bırakma döngüsü alabilir !

Bana öyle geliyor ki, bir değişimin tümüyle yayınlanmasının çoklu serbest bırakma çevrimleri alması insan hatası için çok fazla potansiyel oluşturuyor. Bağlantılı makalede, 2 sürüm için kod değişikliklerinin gerekli olduğunu ve 3 sürüm için bir veritabanı geçişinin gerekli olduğunu göstermektedir.

Ne için bakıyorum

Şu anda, bir şey yapmayı hatırlamak istiyorsak, sorun yönetim sistemimizde bir karmaşa yaratan ve aynı zamanda yönetim tarafından daha sonraki bir koşuya veya birikintiye taşınabilecek bir bilet oluşturabiliriz; ya da muhtemelen tamamen unutulacak olan bir TODO yorumu oluşturabiliriz.

Aradığım şey, bir TODO yorumunun aleyhinde son teslim tarihine sahip olabileceği ve Sürekli Entegrasyon sistemimizin (kullanacağımız kararsız olan) süresinin dolması halinde yapıyı reddedeceği bir yol.

Örneğin, bir sütunu yeniden adlandırırsak, bunun için ilk geçişi ve kalan iki geçişin oluşturulmasını sağlamak için iki TODO yorumu oluşturabiliriz:

// TODO by v55: Create migration to move constraints to new column, remove references to old column in app
// TODO by v56: Create migration to drop old column

Bunu yapmak oldukça basit görünüyor, ama böyle bir şeyin var olup olmadığını merak ediyorum, çünkü tekerleği yeniden icat etmek istemiyorum.

Ek düşünceler

Buradaki XY probleminden muzdarip olabileceğimi düşünüyorum, yuvarlanan dağıtımların ve mavi / yeşil dağıtımların en iyi uygulama olduğu düşünülürse, veritabanı güncellemelerini daha az acı verici hale getirecek bir çözüm bulamamam garip görünüyor. Tamamen yanlış bir şeye baktığımı düşünüyorsanız, lütfen bir yorumda bana bildirin! Bu, verdiğim veritabanı örneğinin sadece bir örnek olduğunu ve TODO’nun son tarihlere sahip yorumlarının diğer durumlarda da yararlı olacağını düşünüyorum, bu nedenle bu özel duruma tamamen yanlış yaklaşsam bile gerçekten cevaplarımı vermek istiyorum. Asıl soru da. Teşekkürler!

EDIT: Sadece bunun yararlı olabileceği başka bir durum düşündüm. Uygulamanızın parçalarını hazır olduklarında açmak için Özellik Geçişlerini kullanıyorsanız, bunları temizlerken dikkatli olmanız gerekir, aksi halde Geçiş Borcunu kullanabilirsiniz . Son başvuru tarihi olan yorumlar, bunu hatırlamanın iyi bir yolu olabilir.

Bu soru gerçekten bir arada iki soru.

Yapılacaklar yorumları

Aksiyon maddelerini takip etmenin tüm yolları arasında en kötüsü bu TODO yorumları, aktif çalışmalar sırasında veya bir bakıcıya öneri olarak, "ilerde belki daha da geliştirilebilecek bir şey" olarak iyi. Ancak işlerin yapılması konusunda TODO yorumlarına güvenirseniz, başarısızlığa mahkumsunuzdur.

Bu konuda ne yapmalı

TODO yorumları temel olarak teknik borçtur, bu nedenle diğer teknik borçlar gibi ele alınmaları gerekir. Ya vaktınız varsa hemen onları arayın ya da takip edilip önceliklendirilebilmeleri için biriktirmeyin.

Genel olarak konuşursak, bu tamamen tartışılır ve tartışmaya açıktır, TODO yorumları bir kod kokusu olarak kabul edilebilir. Eğer bir TODO yorumu sürüm kontrolüne girene kadar bunu yaparsa, kendinize sormanız gerekir, aslında şu anda bunu takip edecek misiniz? Eğer değilse, sorun değil. Sadece kendinize karşı dürüst olun ve bunu biriktirin.

Bu birikimi nasıl yöneteceğiniz iş sürecine, şirket politikalarına ve belki de bazı kişisel özerkliklere dayanır. Ancak yine de gerçekleşmesini sağlamak için izlenen ve önceliklendirilmiş bir birikime ihtiyacınız var.

Veri tabanı değişiklikleri

Evet, veritabanı değişiklikleri sıfır kesinti politikası ile zor. Daha az acı verici hale getirmek için bazı püf noktaları:

Dağıtım sonrası işlem

Aynı sürümün bir parçası olarak çalışan bir dağıtım sonrası işlem oluşturun. Ancak çalışmasını istiyorsun. En son çalıştığım sistemde 4 aşamalı bir dağıtım tasarladım:

1. preapp veritabanı komut dosyaları
2. ağ uygulamaları
3. postapp veritabanı komut dosyaları
4. bakım penceresi veritabanı komut dosyaları

Buradaki fikir, mümkün olan her yerde, veritabanının mümkün olduğunca çoğunu preapp'e dönüştüreceğimizdir.

Postapp, uyumsuz şema değişiklikleri yapmamız gereken olağandışı vakalara ayrıldı. Bu gibi durumlarda, ön uygulama yeni uygulama kodunu uyumlu hale getirmek için yeterince değişiklik yapabilir (belki de uyumluluk için geçici bir görünüm oluşturabilir) ve postapp bu tür geçici eserleri temizler.

Bakım penceresi aşaması, gerçekten çalışmama süresi gerektiren veya bir canlı dağıtımın riskinin veya maliyetinin buna değmediği durumlarda ayrılmıştır. Örneğin, büyük miktarda veriyi değiştiren komut dosyalarının tüm tabloyu kilitlemesi gerekebilir.

Sık sık dağıtmak

Yeni sürümleri yeterince sık dağıtırsanız, 2 veya 3 sürüm arasında bir değişiklik yapmanın önemsiz olduğu bir noktaya ulaşabilirsiniz. Uzun sürüm döngüleri, veritabanı değişikliklerinin maliyetini yükseltir.

TODO kullanmayın. Projenizde zaten bir TODO listeniz var. Buna sorun izleyici denir.

Bence asıl sorun şu cümle içinde:

sorun yönetimi sistemimizde, karmaşa yaratan ve daha sonra bir sprint veya birikime yönetim tarafından taşınabilecek bir bilet yaratabiliriz.

Sorun izleyiciniz çok fazla karışıklığa yol açarsa, bunu düzeltmenin yollarını bulun. Belki de daha az töreni içeren özel bir konu tipi / etiketi. Belki alt konular. Belki bütünüyle daha az tören. Gerçekten söyleyemeyiz. Ancak, sorun izleyiciniz çok fazla iş yaratıyorsa, insanlar kamuya açık bir forumda yalnızca bu konuyu eklemek yerine ayrıntılı bir soru formüle etmeyi tercih ediyorlarsa, bir şeyler gerçekten yanlış olur.

Yönetiminiz bir görevin son kısmını gereğinden fazla geciktirirse, iki seçeneğiniz vardır:

1. Bunun neden kötü bir fikir olduğunu yönetiminize bildirin.

2. tek bir görev olarak halledin. Bu altın standart çözüm olabilir. Mükemmel bir dünyada, her adımda ihtiyaç duyulan üç değişikliği yapabilmelisiniz. Birini ana şubeye uygula, kurulmasına ve dağıtmasına izin ver. Bu arada ikincisini ana şubeye uygulayın, her şeyin aynı sprint içinde olmasını ve yapılmaması durumunda oluşmasını ve konuşlandırılmasını sağlayın. Belki otomatik olarak bir şey bile bir dağıtım mantıklı olarak nerede mantıklı, ama aslında 3'e ayrılmıştır.

Aradığım şey, bir TODO yorumunun aleyhinde son teslim tarihine sahip olabileceği ve Sürekli Entegrasyon sistemimizin (kullanacağımız kararsız olan) süresinin dolması halinde yapıyı reddedeceği bir yol.

İstediğin şey, işi yapmaya ve takip etmeye istekliysen yapılabilir.

// TODO by v55: Kısıtlamaları yeni sütuna taşımak için taşıma oluşturun, uygulamadaki eski sütuna yapılan başvuruları kaldırın // TODO by v56: Eski sütunu bırakmak için taşıma oluşturun

için grep //TODO by v55o V55 dağıtmak için zamanı geldiğinde. Deploy build, bunu bir entegrasyon testi olarak yapan bir betiği çalıştırır.

55'i sürüm izlemenize bağlayabilir ya da sadece onun için isteyebilirsiniz.

55 yaparken // TODO'yu v54 ile kontrol etmek istiyorsanız ilginçleşir. Aksi halde 55 kez kod tabanında arama yapın. Sonra bu sonucu 1 - 55 arasında filtreleyin. Şimdi 56 bir başarısızlığı tetiklemeyecek.

"Ah, buna ihtiyacımız olmayacak. Bunları her çekimiz olduğu sürece düzelteceğiz" diyebilirsiniz. Hayır. Hayır yapmayacaksın.

Ekibimizde de benzer bir sorun yaşadık. Bunu çözmek için, bu TODO'ları ele alan statik bir analiz kontrolü yazdık. JIRA sorununu veya başvuruda bulundukları Git Sayıyı kontrol ederek. Belirtilen sayı "Geliştirilme" sütununda ilerlerken derlememiz başarısız oluyor.

Bu nedenle, rahatlıkla TODO'ları, unutulmaları konusunda endişelenmeden alabiliriz.

Java'da bunun açık kaynaklı bir uygulamasını yarattım. Evet, bir feragatname, bunu yazdığım, ancak tamamen açık kaynaklı ve lisanslı olduğunu söylediğim gibi.

Aracı denir Westie ve JIRA sorunu denetleyicisi README.md üzerinde bir örneğini. Ayrıca bkz. GitIssueAnalyser.

Başka bir sorunuz varsa, kendinize terfi etmemek için bana bir mesaj gönderin. Kullanmaya karar verirseniz ve herhangi bir öneriniz varsa, lütfen github ile ilgili sorunları dile getirin.

Yapma. Şimdi yap.

TLDR: DB betiklerinizi daha sonra değil şimdi yazın (ve test edin); sadece onları kodlayın, böylece onların yürütülmesi DB versiyonuna göre yapılmalıdır.

Örnek

Örnek olarak, uluslararası hale gelirken ortak bir gereksinim SSNolan bir sütun adını değiştirmek istediğinizi düşünelim TaxID.

Bunu gerçekleştirmek için, belki geçici olarak hem TaxIDbir SSNsütun hem de bir sütun olacaktır. Her iki sürümü de desteklerken, birini diğerinden güncellemek için bir tetikleyiciniz olacaktır. Ancak bu tetiği süresiz olarak tutmak istemezsiniz, bu yüzden daha sonra, geriye dönük uyumluluk artık gerekli olmadığında, bu tetiğin kaldırılmasını (ve SSNsütun düştü) istersiniz . Bunların hepsini ToDo ürünlerine ihtiyaç duymadan kodlayacağız.

Örneğimizde, inşa 101 (ki olmayan) ile uyumluluğu korurken, derleme 102'yi (yeni sütuna sahip) dağıtacağız.

İşte adımlar.

1. Sürüm tablosu oluştur

1. Configurationİki sütunla çağrılan tek bir tablo ekleyin Nameve Value.

2. Name"TargetVersion" ifadesiyle bir satır ekleyin ve Valuedağıtılacak yeni derlemenin sürümünü ayarlayın .

3. Name"CompatibleWith" ile bir satır ekleyin Valueve dağıtımın uyumlu olması gereken minimum sürüm numarasına ayarlayın .

Her dağıtımdan önce bu satırları inceleyin ve güncelleyin.

2. Dağıtım komut dosyalarını değiştirin

1. TaxIDYan yana yeni bir sütun oluşturan SSNve onu SSNsütundan dolduran bir komut dosyası ekleyin . IfTargetVersion'ı kontrol eden bir ifadeye bu kodu ekleyin; Hedef sürüm çok düşükse (yani TaxIDhenüz gerekli değil), atlayın.

   SELECT @TargetVersion = TargetVersion FROM Configuration
   IF @TargetVersion < '102' THEN RETURN
   ALTER TABLE Customer ADD COLUMN taxID VarChar(12) NOT NULL
   UPDATE Customer SET TaxID = SSN
   

2. TaxIDEklerken veya güncellerken SSNve tersi durumda oluşan bir tetikleyici oluşturan bir komut dosyası ekleyin . Bu kodu If, hedef sürümü ve uyumlu sürümü kontrol eden bir ifadeye dahil edin; TargetVersion çok düşükse ( TaxIDgerekmiyorsa) veya CompatibleWith versiyonu çok yüksekse ( SSNalan gerekli değil) atlayın .

   SELECT @TargetVersion  = TargetVersion,
          @CompatibleWith = CompatibleWith 
   FROM Configuration
   IF @TargetVersion  < '102' THEN RETURN
   IF @CompatibleWith > '101' THEN RETURN
   CREATE TRIGGER SSNAndTaxIDTrigger ON Customer etc.
   

3. SSNSütunu kaldırmak için bir komut dosyası ekleyin . IfYalnızca CompatibleWith sürümü yeterince yüksekse ( SSNartık gerekli değildir) sütunu kaldıran bir ifadeye yerleştirin .

   SELECT @CompatibleWith = CompatibleWith FROM Configuration
   IF @CompatibleWith <= '101' THEN RETURN
   IF OBJECT_ID('SSNAndTaxIDTrigger') IS NOT NULL DROP TRIGGER SSNAndTaxIDTrigger
   IF EXISTS (SELECT * FROM syscolumns c JOIN sysobject o ON o.id = c.is WHERE o.Name = 'Custeomr' AND c.Name = 'SSN') BEGIN
       ALTER TABLE Customer DROP COLUMN SSN
   END
   

3. Test

Üretiminizi desteklemek istediğiniz herhangi bir Blue / Green sürüm numarası kombinasyonuyla dağıtımınızı test ettiğinizden emin olun. ConfigurationQA ortamınızdaki tabloyu işleyerek kod hazır olur olmaz test edebilirsiniz .

4. Dağıtım oyun kitabınızda

CompatibleWith sürümünü ve TargetVersion satırlarını güncellemek için bir mühendis için bir adım ekleyin. Mavi'yi konuşlandırıyorsanız, TargetVersion'u Mavi'nin sürüm numarasına ve CompatibleWith sürümünü Yeşil'in sürüm numarasına ayarlayın; Yeşil'i dağıtıyorsanız, onları tersten

tuzaklar

Dağıtım komut dosyalarınızın başvuruda bulunması ve bu DB tablosunda tutulan sürüm numaralarına güvenmesi tamamdır . Çalışma zamanı kodu DEĞİL.

Sürüm numaralarını incelemek için çalışma zamanı kodunuzu yazmaya başlarsanız, uygulamanızda potansiyel olarak büyük bir bakım sorunu olabilecek yeni bir karmaşıklık düzeyi tanıtıyorsunuzdur. Her çalışma zamanı yürütme yolu test edilmelidir; ileriye dönük bu koşulları yerine getirirseniz, KG'nin, her salıverme ile onları doğrulamak için bir ağrı matrisi koymak zorunda kalacak . Benim tavsiyem, böyle dağıtım koşullarını yalnızca dağıtım komut dosyalarında tutmaktır.

Tüm bunların sonucu

Sonunda, tüm kodları önceden yazabilmeniz (ve de sınamak) çok erken çalıştırılacağından korkmadan yapmalısınız. Ayrıca, kod daha fazla endişelenmenize gerek kalmadan zaman geldiğinde geriye dönük uyumluluk tetikleyicisini temizler.

Bu şekilde, düşündüğünüz zaman tüm kodu önceden yazıp test edebilirsiniz ve bu karışık ToDo yorumlarıyla uğraşmanıza gerek kalmaz.

TODO fikrinizi çok fazla zorluyorsunuz, ama şahsen bununla ilgili bir sorun görmüyorum. Sonunda, göçün üretime geçtiğinden emin olmanın en iyi (ve en kolay) yolu, eğer yapmazsa ünite testinden geçememektir. Eğer sürüm 55 veya daha fazla ise (veya gereksinimler ne olursa olsun) bir istisna atan boş bir geçiş fonksiyonunu engellemeniz bir dakikadan daha kısa bir süre alır.

Daha sonra yayınlamaya çalışırsanız, başarısız bir testle karşılaşacaksınız ve birinin bu istisnayı gerçek bir geçiş koduna dönüştürmesi gerekecek.

Hiç kimse şikayetinin kökenine odaklanmış gibi görünmüyor, bu da veritabanı değişikliklerinin çok fazla sürüm sürdürebilmesi anlamına geliyor. Mavi / yeşil dağıtım programına devam etmek istiyor ve çözüm çoktan orada olmalıydı, ancak bir şeyi kaçırmazsam, açıklaması her iki sistem tarafından paylaşılan yalnızca bir veritabanı olduğunu gösteriyor gibi görünüyor. Bu durumda, gerçek bir Mavi / Yeşil sistem değil. Veritabanının çadırdaki uzun kutup olduğu göründüğü için çoğaltılmalıdır, böylece çevrimdışı sistemde veri tabanı değişikliklerinin tamamlanması için ne kadar süre veya kaç devir sürdüğünün önemi yoktur. tamamen test edilmiştir. Geçici çevrimdışı sistemdeki komut dosyaları, çevrimdışı veritabanını günlük olarak tamamen güncel tutabilir.