Daha önce hiç olmamıştı ve işte yine başlıyoruz!
Bir sonraki projemizde ileride sorun yaşamamak için en başından itibaren Liquibase kullanmaya karar verdik. Görünüşe göre tüm genç ekip üyeleri onu nasıl doğru kullanacaklarını bilmiyor. Dahili bir çalıştay düzenledim ve bunu bir makaleye dönüştürmeye karar verdim.
Makalede, özellikle Liquibase olmak üzere ilişkisel veritabanı geçiş araçlarıyla çalışırken karşılaşabileceğiniz en belirgin üç tuzağa ilişkin yararlı ipuçları ve açıklamalar yer almaktadır. Orta ve Orta seviyedeki Java geliştiricileri için tasarlanmış olup, daha deneyimli geliştiriciler için halihazırda bilinenlerin yapılandırılması ve tekrarlanması açısından ilginç olabilir.
Liquibase ve Flyway, Java dünyasındaki ilişkisel yapıların sürüm kontrol sorunlarını çözmek için birbiriyle rekabet eden başlıca teknolojilerdir. İlki tamamen ücretsizdir, pratikte çoğunlukla kullanım için seçilir, bu nedenle yayının kahramanı olarak Liquibase seçildi. Ancak açıklanan uygulamalardan bazıları uygulama mimarinize bağlı olarak evrensel olabilir.
İlişkisel yapıların taşınması, ilişkisel veri depolarının zayıf esnekliğiyle baş etmenin zorunlu bir yoludur. OOP modası çağında, veritabanlarıyla çalışma tarzı, şemayı bir kez tanımlayıp bir daha ona dokunmamamız anlamına geliyordu. Ancak gerçek şu ki, işler her zaman değişir ve tablo yapısında değişiklik yapılmasına sıklıkla ihtiyaç duyulur. Doğal olarak sürecin kendisi acı verici ve nahoş olabilir.
Teknolojinin açıklamasına ve projenize kitaplık ekleme talimatlarına daha derinlemesine girmeyeceğim; bu konuyla ilgili pek çok makale yazıldı:
Ek olarak, yararlı ipuçlarıyla ilgili mükemmel bir makale zaten vardı:
Советы
Göçle ilgili sorunları çözmenin teri, kanı ve acısıyla doğan tavsiye ve yorumlarımı paylaşmak istiyorum.
1. Çalışmaya başlamadan önce en iyi uygulamalar bölümünü okumalısınız. likibaz
Basit ama çok önemli şeyler anlatılıyor; bunlar olmadan kütüphaneyi kullanmanın hayatınızı zorlaştırabileceği belirtiliyor. Örneğin, değişiklik kümelerini yönetmeye yönelik yapılandırılmamış bir yaklaşım, er ya da geç kafa karışıklığına ve geçişlerin kesintiye uğramasına yol açacaktır. Veritabanı yapısında ve hizmet mantığında karşılıklı olarak bağımlı değişiklikleri aynı anda uygulamaya koymazsanız, bunun kırmızı testlere veya bozuk bir ortama yol açma olasılığı yüksektir. Ek olarak, resmi web sitesindeki Liquibase kullanımına ilişkin öneriler, ana geçiş komut dosyalarının yanı sıra geri alma komut dosyalarının geliştirilmesi ve test edilmesine ilişkin bir madde içerir. Peki, makalede Geçişler ve geri alma mekanizmasıyla ilgili kod örnekleri vardır.
2. Geçiş araçlarını kullanmaya başlarsanız veritabanı yapısında manuel düzeltmelere izin vermeyin
Diyor ki: “Bir kez Persil, her zaman Persil.” Uygulamanızın tabanı Liquibase tarafından yönetilmeye başlarsa, manuel olarak yapılan herhangi bir değişiklik anında tutarsız bir duruma yol açar ve değişiklik setlerine olan güven düzeyi sıfır olur. Potansiyel riskler arasında veritabanını geri yüklemek için harcanan birkaç saat; en kötü senaryoda sunucunun ölmesi yer alır. Ekibinizde "eski tarz" bir DBA Mimarı varsa, sabırla ve düşünceli bir şekilde, veritabanını koşullu bir SQL Geliştiricisinden kendi anlayışına göre düzenlerse işlerin ne kadar kötü olacağını ona açıklayın.
3. Değişiklik kümesi zaten depoya aktarılmışsa düzenleme yapmaktan kaçının
Başka bir geliştirici, daha sonra düzenlenecek olan bir değişiklik seti çekip uyguladıysa, uygulamayı başlatırken bir hata aldığında sizi kesinlikle nazik bir sözle hatırlayacaktır. Değişiklik setini düzenlemek bir şekilde geliştirme sürecine sızıyorsa, düzeltmelerin kaygan zeminini takip etmeniz gerekecektir. Sorunun özü, Liquibase'in ana mekanizması olan karma toplamına göre değişikliklerin doğrulanmasına dayanmaktadır. Değişiklik kümesi kodunu düzenlerken karma miktarı değişir. Değişiklik kümelerini düzenlemek yalnızca tüm veritabanını veri kaybı olmadan sıfırdan dağıtmak mümkün olduğunda mümkündür. Bu durumda, SQL veya XML kodunu yeniden düzenlemek, tam tersine, hayatı kolaylaştırabilir ve geçişleri daha okunabilir hale getirebilir. Örnek olarak, uygulamanın başlangıcında ekip içinde kaynak veritabanı şeması üzerinde anlaşmaya varılan bir durum verilebilir.
4. Mümkünse veritabanı yedeklerini doğrulayın
Burada her şeyin açık olduğunu düşünüyorum. Geçiş aniden başarısız olursa, her şey geri döndürülebilir. Liquibase'in değişiklikleri geri almak için bir aracı vardır, ancak geri alma komut dosyaları da geliştiricinin kendisi tarafından yazılır ve ana değişiklik kümesinin komut dosyalarıyla aynı olasılıkla sorun yaşayabilirler. Bu, her durumda yedeklemelerle güvenli bir şekilde oynamanın faydalı olduğu anlamına gelir.
5. Mümkünse geliştirme aşamasında kanıtlanmış veritabanı yedeklerini kullanın
Bu, sözleşmelere ve gizliliğe aykırı değilse, veritabanında kişisel veri yoktur ve iki güneş kadar ağır değildir - canlı geçiş sunucularında kullanmadan önce geliştiricinin makinesinde nasıl çalışacağını kontrol edebilir ve hesaplayabilirsiniz. Geçiş sırasındaki potansiyel sorunların neredeyse %100'ü.
6. Ekipteki diğer geliştiricilerle iletişim kurun
İyi organize edilmiş bir geliştirme sürecinde ekipteki herkes kimin ne yaptığını bilir. Gerçekte durum çoğu zaman böyle değildir, bu nedenle, görevinizin bir parçası olarak veritabanı yapısında değişiklikler hazırlıyorsanız, ek olarak tüm ekibi bu konuda bilgilendirmeniz tavsiye edilir. Birisi paralel olarak değişiklik yapıyorsa dikkatli bir şekilde organize olmalısınız. İş arkadaşlarınızla sadece başlangıçta değil, işi bitirdikten sonra da iletişim kurmaya değer. Değişiklik kümeleriyle ilgili birçok potansiyel sorun, kod inceleme aşamasında çözülebilir.
7. Ne yaptığınızı düşünün!
Her durum için geçerli olan apaçık bir tavsiye gibi görünebilir. Ancak geliştiricinin ne yaptığını ve bunun neyi etkileyebileceğini bir kez daha analiz etmesi durumunda birçok sorunun önüne geçilebilirdi. Geçişlerle çalışmak her zaman ek dikkat ve doğruluk gerektirir.
tuzakları
Şimdi yukarıdaki tavsiyelere uymazsanız düşebileceğiniz tipik tuzaklara bakalım ve tam olarak ne yapmalısınız?
Durum 1: İki geliştirici aynı anda yeni değişiklik kümeleri eklemeye çalışıyor
Vasya ve Petya birbirlerinden habersiz 4. versiyon değişiklik setini oluşturmak istiyorlar. Veritabanı yapısında değişiklikler yaptılar ve farklı değişiklik seti dosyalarıyla bir çekme isteği yayınladılar. Aşağıdaki etki mekanizması önerilmektedir:
Nasıl karar verilir?
- Bir şekilde meslektaşlarının değişiklik setlerinin hangi sırayla gitmesi gerektiği konusunda anlaşmaları gerekiyor; örneğin ilk olarak Petin uygulanmalı.
- Birisi ikincisini kendine eklemeli ve Vasya'nın değişiklik setini 5. versiyonla işaretlemeli. Bu, Cherry Pick veya düzgün bir birleştirme yoluyla yapılabilir.
- Değişikliklerden sonra yapılan işlemlerin geçerliliğini mutlaka kontrol etmelisiniz.
Aslında Liquibase mekanizmaları, depoda iki adet sürüm 4 değişiklik setine sahip olmanıza izin verecektir, böylece her şeyi olduğu gibi bırakabilirsiniz. Yani, sürüm 4'te farklı adlarla iki değişiklik yapacaksınız. Bu yaklaşımla daha sonra veritabanı sürümlerinde gezinmek çok zor hale gelir.
Ayrıca Liquibase, hobbitlerin evi gibi birçok sır saklıyor. Bunlardan biri, sürüm 1.7'de görünen ve veritabanında ne depolandığına bakılmaksızın belirli bir değişiklik kümesi için geçerli bir karma değeri belirtmenize olanak tanıyan validCheckSum anahtarıdır. Dokümantasyon şunları söylüyor:
Veritabanında ne depolandığına bakılmaksızın, bu changeSet için geçerli sayılan bir sağlama toplamı ekleyin. Öncelikle bir changeSet'i değiştirmeniz gerektiğinde ve üzerinde çalıştığı veritabanlarında hataların oluşmasını istemediğinizde kullanılır (önerilen bir prosedür değildir)
Evet, evet, bu prosedür önerilmez. Ancak bazen güçlü bir ışık sihirbazı aynı zamanda karanlık tekniklerde de ustalaşır
Durum 2: Verilere bağlı geçiş
Canlı sunuculardaki veritabanı yedeklerini kullanma olanağınızın olmadığını varsayalım. Petya bir değişiklik seti oluşturdu, bunu yerel olarak test etti ve haklı olduğuna tamamen güvenerek geliştiriciye bir çekme talebinde bulundu. Her ihtimale karşı proje lideri Petya'nın bunu kontrol edip etmediğini açıkladı ve ardından ekledi. Ancak geliştirme sunucusundaki dağıtım düştü.
Aslında bu mümkündür ve hiç kimse bundan muaf değildir. Bu, tablo yapısındaki değişikliklerin bir şekilde veritabanındaki belirli verilere bağlanması durumunda meydana gelir. Açıkçası Petya'nın veri tabanı yalnızca test verileriyle doluysa tüm sorunlu durumları kapsamayabilir. Örneğin bir tabloyu silerken, yabancı anahtara göre başka tablolarda silinen tablodaki kayıtlarla ilgili kayıtların olduğu ortaya çıkıyor. Veya sütun türünü değiştirirken verilerin %100'ünün yeni türe dönüştürülemediği ortaya çıkıyor.
Nasıl karar verilir?
- Geçişle birlikte bir kez kullanılacak özel scriptler yazın ve verileri uygun forma getirin. Bu, geçişleri uyguladıktan sonra verileri yeni yapılara aktarma sorununu çözmenin genel bir yoludur, ancak özel durumlarda benzer bir şey daha önce de uygulanabilir. Bu yol elbette her zaman mevcut değildir çünkü canlı sunuculardaki verileri düzenlemek tehlikeli ve hatta yıkıcı olabilir.
- Bir başka zor yol da mevcut bir değişiklik kümesini düzenlemektir. Zorluk, mevcut haliyle zaten uygulanmış olan tüm veritabanlarının geri yüklenmesi gerekmesidir. Tüm arka uç ekibinin veritabanını sıfırdan yerel olarak kullanıma sunmak zorunda kalması oldukça olasıdır.
- Ve en evrensel yol, verilerle ilgili sorunu geliştiricinin ortamına aktarmak, aynı durumu yeniden oluşturmak ve bozuk olana sorunu aşacak yeni bir değişiklik seti eklemektir.
Genel olarak, veritabanı kompozisyon açısından üretim sunucusu veritabanına ne kadar benzerse, geçişlerle ilgili sorunların ileri gitme olasılığı da o kadar az olur. Ve elbette, depoya bir değişiklik seti göndermeden önce, bunun herhangi bir şeyi bozup bozmayacağını birkaç kez düşünmelisiniz.
Durum 3. Liquibase üretime girdikten sonra kullanılmaya başlanır
Ekip liderinin Petya'dan Liquibase'i projeye dahil etmesini istediğini ancak projenin halihazırda üretim aşamasında olduğunu ve mevcut bir veritabanı yapısının bulunduğunu varsayalım.
Buna göre sorun, yeni sunucularda veya geliştirici makinelerde bu tabloların sıfırdan yeniden oluşturulması ve mevcut ortamın yeni değişiklikleri kabul etmeye hazır, tutarlı bir durumda kalması gerektiğidir.
Nasıl karar verilir?
Ayrıca birkaç yol vardır:
- Bunlardan ilki ve en bariz olanı, yeni bir ortamı başlatırken manuel olarak uygulanması gereken ayrı bir komut dosyasına sahip olmaktır.
- İkincisi daha az belirgindir; başka bir Liquibase Bağlamında bulunan bir Liquibase geçişine sahip olun ve bunu uygulayın. Liquibase İçeriği hakkında daha fazla bilgiyi buradan edinebilirsiniz: . Genel olarak bu, örneğin test için başarıyla kullanılabilecek ilginç bir mekanizmadır.
- Üçüncü yol birkaç adımdan oluşur. Öncelikle mevcut tablolar için bir geçiş oluşturulmalıdır. Daha sonra bir ortama uygulanması gerekir ve böylece hash toplamı elde edilir. Bir sonraki adım, boş olmayan sunucumuzda boş Liquibase tablolarını başlatmaktır ve değişiklik kümelerinin kullanım geçmişini içeren tabloya, veritabanında zaten mevcut olan değişikliklerle "uygulanmış gibi" değişiklik kümesi hakkında manuel olarak bir kayıt koyabilirsiniz. . Böylece mevcut bir sunucuda geçmiş geri sayımı sürüm 2'den başlayacak ve tüm yeni ortamlar aynı şekilde davranacaktır.
Durum 4. Göçler çok büyük hale geliyor ve tamamlanacak zamanları yok
Hizmet geliştirmenin başlangıcında kural olarak dış bağımlılık olarak Liquibase kullanılır ve uygulama başlatıldığında tüm geçişler işlenir. Ancak zamanla aşağıdaki durumlarla karşılaşabilirsiniz:
- Göçler çok büyük boyutlara ulaşıyor ve tamamlanması uzun zaman alıyor.
- Dağıtılmış ortamlarda, örneğin aynı anda birden fazla veritabanı sunucusu örneğinde geçiş yapılmasına ihtiyaç vardır.
Bu durumda, geçişlerin çok uzun süre uygulanması, uygulama başlatıldığında zaman aşımına uğramasına neden olacaktır. Ayrıca, geçişlerin her uygulama örneğine ayrı ayrı uygulanması, farklı sunucuların senkronizasyonunun bozulmasına neden olabilir.
Nasıl karar verilir?
Bu gibi durumlarda projeniz zaten büyüktür, hatta belki bir yetişkindir ve Liquibase ayrı bir harici araç olarak hareket etmeye başlar. Gerçek şu ki, Liquibase bir kütüphane olarak bir jar dosyasında derlenmiştir ve bir proje içinde veya bağımsız olarak bir bağımlılık olarak çalışabilir.
Bağımsız modda, geçişlerin uygulanmasını CI/CD ortamınıza veya sistem yöneticilerinizin ve dağıtım uzmanlarınızın güçlü omuzlarına bırakabilirsiniz. Bunu yapmak için Liquibase komut satırına ihtiyacınız olacak . Bu modda gerekli tüm geçişler gerçekleştirildikten sonra uygulamayı başlatmak mümkün hale gelir.
Aviator apk
Aslında veritabanı geçişleriyle çalışırken çok daha fazla tuzakla karşılaşılabilir ve bunların çoğu yaratıcı bir yaklaşım gerektirir. Aracı doğru kullanırsanız bu tuzakların çoğunun önlenebileceğini anlamak önemlidir. Özellikle sıralanan sorunların hepsiyle farklı şekillerde uğraşmak zorunda kaldım ve bunların bir kısmı benim hatalarımdan kaynaklandı. Çoğunlukla bu, elbette dikkatsizlik nedeniyle olur, ancak bazen de aracı cezai olarak kullanamama nedeniyle olur.
Kaynak: habr.com