“Tüm ürünler için tek bir büyük VCS deposundan” organizasyon modelinden “çok sayıda küçük VCS deposu” modeline sorunsuz bir geçiş nasıl sağlanır?

Bazı VCS sistemlerinde bir depo tarafından tutulan bir ürünün kod tabanının, kod tabanının muhtemelen birkaç ürün içerdiği düşünülebilecek bir noktaya dönüştüğü yaygın bir senaryodur . Kod tabanının, her biri tek bir ürüne ayrılan birkaç VCS havuzuna bölünmesi birkaç avantajdan yararlanabilir (bkz . Aşağıdaki şişirme veri havuzu modeli üzerinde VCS veri havuzu başına bir ürüne sahip olmanın avantajları ). Teknik açıdan, çoğu VCS bu işlemi desteklediğinden kod tabanını bölmek oldukça kolay bir adımdır. Bölünmüş ancak otomatik test, sürekli teslimat, hizmet entegrasyonu veya izleme ile ilgili mühendislik konuları yükselebilir (bkz Sorunlar bölünmüş tarafından gündemeBu nedenle böyle bir bölünme yapmayı planlayan kuruluşların, bu geçişin mümkün olduğunca sorunsuz bir şekilde nasıl gerçekleştirileceğini, yani dağıtım ve izleme boru hattını kesintiye uğratmadan nasıl bilmesi gerektiğini bilmesi gerekir. Bunun ilk adımı, muhtemelen proje kavramını ve monolitik bir kod tabanındaki bölünmenin nasıl tanımlanacağını daha iyi anlamaktır .

Bu soruların cevaplarında şunu görmek istiyorum:

1. Mevcut bir kod tabanındaki ürünleri gerçekten tanımlamak için pratik kriterler veren, ürünün ne olduğunun çalışma tanımını verme girişimi.

2. Bu çalışma tanımına göre, gerçekten bölünmeyi gerçekleştiren bir plan hazırlayın. Kod tabanının, sürekli entegrasyon ve sürekli dağıtım uygulayan tam otomatik bir sdlc tarafından işlendiği basitleştirici varsayımı yapabiliriz . Diğer bir deyişle, her dal, geçerli kod tabanına uygulanan otomatik bir testsuite tarafından doğrulanır ve her bir "sihirli" dalla birleştirildiğinde , test edilen ve dağıtılan ürün artefaktları oluşturulur . ( Ürün artefaktları , örneğin kaynak tarballs, dokümantasyon, ikili yazılım paketleri, Docker görüntüleri, AMI'ler, unikernellerdir.)

3. Böyle bir plan,

Bölünme ile ortaya çıkan sorunlar

1. Otomatik test prosedürleri önceden var olan monolitik depo ve bölünmüş depolarla nasıl ilişkilidir?

2. Otomatik dağıtım prosedürleri önceden var olan yekpare depo ve bölünmüş depolarla nasıl ilişkilidir?

3. Otomatik dağıtım yordamlarının kodları nerede saklanır?

4. Depolanmış altyapı , izleme ve yüksek kullanılabilirlik stratejileri nerede?

5. Bir geliştiricinin bir kerede yalnızca bir kod tabanına ihtiyaç duyması nasıl sağlanır (ancak olası diğer kod tabanlarındaki eserleri kullanır).

6. Git-Bisect gibi bir araç nasıl

Marjinal not: VCS veri havuzu başına şişkin depo modeli üzerinde bir ürün bulundurmanın faydaları

Belirli bir ürün için kod tabanını tutan birkaç küçük depoya sahip olmak, “şişirmeli depo” yaklaşımına göre aşağıdaki avantajlara sahiptir:

1. Bir şişkinlik deposuyla, bir ürün kararsız olduğunda bir sürümü geri almak zordur, çünkü geçmiş diğer ürün geçmişiyle karıştırılır.

2. Bir şişkinlik deposuyla, proje geçmişini veya çekimleri gözden geçirmek zordur, küçük depolarla bu bilgileri okuma olasılığımız daha yüksektir. (Bu, git gibi VCS'ye özgü olabilir, svn'den farklı olarak, alt ağaçlara ödeme yapamayız!)

3. Bir şişkinlik deposu ile geliştiğimizde çok daha fazla şube dansı yapmak zorundayız. N depomuz varsa, N dalında paralel olarak çalışabiliriz, sadece 1 depomuz varsa, yalnızca bir dalda çalışabiliriz veya işlenmesi zor olan bir sürü çalışan kopyaya sahip olabiliriz.

4. Birkaç küçük depoda, kütükler projenin ısı haritasını verir. Geliştirme ekibinde bilgi yayılımının bir vekili olarak bile kullanılabilirler: 3 aydan beri repo X'te taahhütte bulunmazsam, gelişmelerden haberdar olmak için beni repo X üzerinde çalışan bir ekibe atamak iyi olabilir. bu bileşende.

5. Küçük depolarla, bir bileşene net bir genel bakış elde etmek daha kolaydır. Her şey tek bir büyük depoya girerse, her bir bileşeni tanımlayan somut bir eser yoktur ve kod tabanı kolayca büyük çamur topuna doğru kayabilir .

6. Küçük depolar bizi bileşenler arasındaki arabirimler üzerinde çalışmaya zorlar. Ancak iyi bir kapsülleme yapmak istediğimiz için, bu zaten yapmamız gereken bir iş, bu yüzden bunu küçük depolar için bir avantaj olarak sayacağım.

7. Birkaç küçük depo ile birkaç ürün sahibine sahip olmak daha kolaydır.

8. Birkaç küçük depoda, tam bir depo ile ilgili olan ve otomatik olarak doğrulanabilen basit kod standartlarına sahip olmak daha kolaydır.

Bu gerçek cevapların gerçekte var olamayacağı büyüleyici bir sorudur; Soruyu VCS üzerinde bağlamsal tutmaya çalışırken, doğal olarak kendi başına altyapı tasarımı ve uygulama planlamasına göre ölçeklendirildiğini takdir ediyorum.

Yine de, çoğumuz heyecan verici olabilen, ancak aynı zamanda çok sinir bozucu ve acı verici olan bu tür bir geçiş üzerinde çalışıyoruz; bilgelik ve görüşlerimi paylaşmak, bilgiçlikten uzak olmamak ve sadece iyi bir mühendis olmamam, sıkıcı olmamam.

tasarlamak

Modern bir yazılım yazmak için altyapı ve mimari birlikte gitmelidir. İsterseniz sıkıca bağlı. Bu kelimeleri kullanmak garip gelebilir, ancak burada kodun kendisinden kesinlikle bahsetmiyoruz: Yani aynı planın bir parçası olmalılar. Bulutlar geldiğinde ve insanlar onlar için yazılım yazmaya başladığında, o zaman kaç kişi çamur toplarını oraya koyarak, sadece farklı bir yerde aynı çamur topları olacağını fark ettiler (?) ve muhtemelen devopsilerde çalışıyorlar. Adanmışlar sadece farklı insanlar için farklı anlamlara sahip bir terim olduğu için, adanmışlar ekibinin her mimari toplantıda oturacağı yerler gördüm; sadece otomasyon olan diğer yerler. Bu tür bir dönüşüme ulaşmak için orada oturmak için mücadele etmeliyiz.

Güven

Geçiş, başka bir değişiklik olmaksızın (birkaç aylık hazırlıktan sonra) geçişin kendisini ve kendisini sağlayan tutarlı bir tarih kesintisi olması gerektiği anlamında izole tutulmalıdır. Hangi güvenle, onu onaylar ve kırmızı düğmeye basar?

Yani, kod tabanının yeni VCS yapısına uyacak şekilde değişmesi gerekiyor ve geliştirme sırasında birleştirilmesi çok zor olacak. (bu sorun için kolaylaştırıcı stratejiler olabilir, daha sonra ortak bir stratejiden bahsedeceğim, bu da gelişmeyi biraz paralelleştirmeye yardımcı olabilir).

Eminim tek yolu davranış testi ile ve eski yeni kod temeli ile doğrulamak için aynı davranış testleri paketi başlatılmalıdır. Uygulamanın burada beklendiği gibi davrandığını doğrulamıyoruz, ancak geçişin davranışı değiştirmediği doğrulanıyor. Başarısız testlere sahip olmak iyi bir şey olabilir! Eğer başarısız olmaya devam ederse!

Aslında, çamur toplarının iyi test edilmesi çok nadirdir; genellikle kod çok sıkı bir şekilde birleştirilir ve muhtemelen eski kodların çoğunda, birim testler bile değil, test odaklı bir yaklaşımla geliştirilmemiştir.

Böyle bir test kodu eksikse, önce yazılmalıdır.

strateji

Evet, geçiş izole tutulmalıdır; ama aynı zamanda entegre. Burada çılgınca gelebileceğimi biliyorum, ama güvenin işe nasıl devam edebileceğini açıklayan başka kelimeler bulamazdım. Çok az, eğer hiç değilse, şirketler büyük bir monolitik kod temeli için gelişimi durdurmak, bu geçişe yer açmak istiyorlar ve biz bunu sadece bir madalyonun içinde bırakmıyoruz. Belki de yüzlerce geliştirici kod tabanına sürekli katkıda bulunuyor olabilir (POV'umuzdan kurcalama kelimesini kullanırım ). İşimiz güven sağlamak için belirli bir anlık görüntüyü ele alsa da, sonsuza kadar geride kalmamak için kendimizi yeniden temellendirmeliyiz (burada bir anlam ifade etmiyoruz).

Buradaki uygulama stratejisi farklı deneyimler verebilir. Ortak bir geliştirme çizgisi, çekirdekle etkileşim kurmaları gerektiğinde yeni uygulama dallarını (isteğe bağlı olarak yeniden düzenlenmiş şemalarla uç noktalarını ortaya çıkarmak) sarmak / uyarlamaktır (bu durumda diğer havuzlarda yaşamak). Yeniden düzenleme ile birlikte böyle bir stratejiyle geçiş, aynı zamanda VCS geçişi için bir POC senaryosu ve daha sonra adım adım bir yaklaşım sunabilir. Çamur topunu şekillendirmek gibi görün. Evet hayat çok daha komik şeyler sunuyor.

Teknik borç

İş yönetimi alanları teknik borcu anlamaya ve dikkate almaya başladı. Hayır, çizik, doğru değil. Statik kod analizi, kod inceleme, davranışsal test sonuçları ve performans açısından ölçümler ve kalite verileri toplamak giderek yaygınlaşıyor olsa da, güzel raporlar ve her şey üretiliyor ... yeniden düzenleme yaklaşımı. İş değeri o. "Çevik bir süreci takip ediyoruz ve bu özelliklerde herhangi bir gelişme sağlamayacak, değil mi?" . Temel olarak, bunu yaparak teknik borcun varlığını reddediyorlar. Bunu monolitten mikro hizmet mimarilerine herhangi bir geçişe başlayabilmek için ortak eksik gerekli adım olarak görüyorum.

reaggregation

Tüm bunlardan sonra, birden fazla ürün oluşturabileceğiniz tek bir depo benzeri görünüm sağlamak isteyebilirsiniz. Herhangi bir nedenle, yani curr / sonraki sürüm, çoklu marka, müşteri yapıları. Google repo gibi araçlar bu durumda yardımcı olabilir. Hiç kendim kullanmadım, ama bir güne ihtiyacım olacağını biliyorum.

Entegrasyon testi

Mikro hizmetlerde, entegrasyon testi "kendi API'sini test etme" den farklı bir bağlam alır. Daha yüksek test katmanları, fonksiyonel veya performans var olabilir ve olacaktır, ancak uygun entegrasyon testi olmadan çok şey ifade ediyorlar mı? Birim testi olmadan entegrasyon testine sahip olmak gibi bir şey. Tabii ki değil. Bu nedenle, bisect'e gitmeniz gerekiyorsa, bunu bir mikro hizmet deposu dalında yürütür, bunu çamur topu deposunda çalıştırmayı unutursunuz.

PS. bu bir taslak, İngilizcem kötü ve bir gün tamir edeceğim