Ders öğrencileri için hazırlanan makalenin tercümesi "DevOps uygulamaları ve araçları" OTUS eğitim projesinde.

Tek depo seçmelisiniz çünkü ekiplerinizde teşvik ettiği davranış, özellikle ekipler büyüdükçe şeffaflık ve paylaşılan sorumluluktur. Her iki durumda da, araçlara yatırım yapmanız gerekecektir, ancak varsayılan davranışın komutlarınızda istediğiniz davranış olması her zaman daha iyidir.

Neden bundan bahsediyoruz?

Makaleyi Matt Klein yazdı "Monorepos: Lütfen yapma!"  (çevirmenin notu: Habré üzerine çeviri “Tek depolar: lütfen yapmayın”). Matt'i seviyorum, bence o çok akıllı ve onun bakış açısını okumalısın. Anketi ilk olarak Twitter'da yayınladı:

Çeviri:
Bu Yeni Yıl Günü, monorepoların ne kadar saçma olduğunu tartışacağım. 2019 sakin başladı. Bunun ruhuyla size bir anket teklif ediyorum. Büyük fanatikler kimlerdir? Destekçiler:
- Monorepo
- Rust
- Yanlış anket / her ikisi

Cevabım şu oldu: "Ben kelimenin tam anlamıyla bu iki insanım." Rust'un nasıl bir ilaç olduğundan bahsetmek yerine, onun monorepolar konusunda neden yanıldığını düşündüğüme bakalım. Kendin hakkında biraz. Chef Software'in CTO'suyum. 100'e yakın mühendisimiz, 11-12 yıllık bir kod tabanımız ve 4 ana ürünümüz var. Bu kodun bir kısmı çoklu depoda (başlangıç ​​konumum), bazıları ise tek depoda (şu anki konumum).

Başlamadan önce: Burada öne sürdüğüm her argüman her iki türdeki depolar için de geçerli olacaktır. Bana göre, bir depo türünü diğerine tercih etmenizin teknik bir nedeni yok. Herhangi bir yaklaşımın işe yaramasını sağlayabilirsiniz. Bunun hakkında konuşmaktan mutluyum ama birinin diğerinden üstün olmasının yapay teknik sebepleriyle ilgilenmiyorum.

Matt'in görüşünün ilk kısmına katılıyorum:

Çünkü geniş ölçekte, bir monorepository, bir polyrepository'nin çözdüğü tüm sorunları çözecektir, ancak aynı zamanda sizi kodunuzu sıkı bir şekilde eşleştirmeye zorlayacak ve sürüm kontrol sisteminizin ölçeklenebilirliğini artırmak için inanılmaz çabalar gerektirecektir.

Tek depo veya çoklu depo seçmenize bakılmaksızın aynı sorunları çözmeniz gerekecektir. Yayınları nasıl yayınlıyorsunuz? Güncellemelere yaklaşımınız nedir? Geriye dönük uyumluluk? Çapraz proje bağımlılıkları mı? Hangi mimari tarzlar kabul edilebilir? Derleme ve test altyapınızı nasıl yönetiyorsunuz? Liste sonsuz. Ve büyüdükçe hepsini çözeceksiniz. Bedava peynir yok.

Matt'in argümanının saygı duyduğum birçok mühendisin (ve yöneticinin) paylaştığı görüşlere benzediğini düşünüyorum. Bu, bileşen üzerinde çalışan mühendisin veya bileşen üzerinde çalışan ekibin bakış açısından ortaya çıkar. Şuna benzer şeyler duyarsınız:

• Kod tabanı hantal; tüm bu çöplere ihtiyacım yok.
• Test etmek daha zor çünkü ihtiyacım olmayan tüm bu ıvır zıvırı test etmem gerekiyor.
• Dış bağımlılıklarla çalışmak daha zordur.
• Kendi sanal sürüm kontrol sistemlerime ihtiyacım var.

Tabii ki, tüm bu noktalar haklı. Bu her iki durumda da olur - çoklu depoda, yapı için gerekli olana ek olarak kendi çöplerim de var... Başka çöplere de ihtiyacım olabilir. Bu yüzden "basitçe" tüm projeyi kontrol eden araçlar yaratıyorum. Veya alt modüllerle sahte bir monorepository oluşturuyorum. Bütün gün bunun etrafında dolaşabiliriz. Ancak bence Matt'in argümanı, benim ağırlıklı olarak tek depo lehine çevirdiğim ana nedeni gözden kaçırıyor:

İletişimi kışkırtır ve sorunları gösterir

Depoları ayırdığımızda fiili bir koordinasyon ve şeffaflık sorunu yaratıyoruz. Bu, takımlar hakkındaki düşüncelerimize (özellikle bireysel üyelerin onlar hakkındaki düşüncelerine) karşılık gelir: Biz belirli bir bileşenden sorumluyuz. Göreceli olarak izole bir şekilde çalışıyoruz. Ekibimin ve üzerinde çalıştığımız bileşen(ler)in sınırları bellidir.

Mimari daha karmaşık hale geldikçe, bir ekip artık onu tek başına yönetemez. Çok az mühendisin kafasında sistemin tamamı vardır. Diyelim ki, B, C ve D Ekipleri tarafından kullanılan paylaşılan bir A bileşenini yönettiğinizi varsayalım. A Ekibi, API'yi yeniden düzenliyor, geliştiriyor ve aynı zamanda dahili uygulamayı da değiştiriyor. Sonuç olarak değişiklikler geriye dönük olarak uyumlu değildir. Ne tavsiyen var?

• Eski API'nin kullanıldığı tüm yerleri bulun.
• Yeni API'nin kullanılamayacağı yerler var mı?
• Kırılmadıklarından emin olmak için diğer bileşenleri tamir edip test edebilir misiniz?
• Bu ekipler değişikliklerinizi şu anda test edebilir mi?

Lütfen bu soruların veri havuzu türünden bağımsız olduğunu unutmayın. B, C ve D takımlarını bulmanız gerekecek. Onlarla konuşmanız, zamanı öğrenmeniz, önceliklerini anlamanız gerekecek. En azından bunu yapacağınızı umuyoruz.

Gerçekten kimse bunu yapmak istemiyor. Bu, lanet API'yi düzeltmekten çok daha az eğlenceli. Her şey insani ve dağınık. Bir çoklu depoda, basitçe değişiklikler yapabilir, bunu o bileşen üzerinde çalışan kişilere (muhtemelen B, C veya D değil) inceleme için verebilir ve devam edebilirsiniz. B, C ve D takımları şimdilik mevcut versiyonlarında kalabilirler. Dehanızı anladıklarında yenilenecekler!

Tek depoda sorumluluk varsayılan olarak kaydırılır. A Takımı bileşenlerini değiştirir ve dikkatli olmazsa hemen B, C ve D'yi kırar. Bu, B, C ve D'nin A Takımının neden montajı bozduğunu merak ederek A'nın kapısına gelmesine yol açar. Bu A'ya yukarıdaki listemi atlayamayacaklarını öğretir. Ne yapacaklarını konuşmalılar. B, C ve D hareket edebilir mi? Ya B ve C yapabiliyorsa ama D eski algoritmanın davranışının bir yan etkisi ile yakından ilişkiliyse?

O halde bu durumdan nasıl çıkacağımızı konuşmalıyız:

1. Birden fazla dahili API'yi destekler ve eski algoritmayı, D onu kullanmayı bırakana kadar kullanımdan kaldırılmış olarak işaretler.
2. Biri eski arayüze, diğeri yeni arayüze sahip birden fazla yayın sürümü desteği.
3. B, C ve D aynı anda kabul edene kadar A'nın değişikliklerinin yayınlanmasını erteleyin.

Diyelim ki 1, birkaç API seçtik. Bu durumda elimizde iki kod parçası var. Eski ve yeni. Bazı durumlarda oldukça kullanışlıdır. Eski kodu tekrar kontrol ediyoruz, kullanımdan kaldırıldı olarak işaretliyoruz ve D ekibiyle esas olarak poli ve mono depolar için aynı olan bir kaldırma planı üzerinde anlaşıyoruz.

Birden fazla sürümü yayınlamak için bir şubeye ihtiyacımız var. Artık iki bileşenimiz var - A1 ve A2. B ve C takımları A2'yi, D ise A1'i kullanır. D'nin ilerlemesi için güvenlik güncellemeleri ve diğer hata düzeltmeleri gerekebileceğinden her bileşenin yayınlanmaya hazır olmasına ihtiyacımız var. Bir çoklu depoda bunu uzun ömürlü, iyi hissettiren bir dalda saklayabiliriz. Tek depoda, kodu yeni bir modülde oluşturulmaya zorlarız. D Takımının yine de "eski" bileşende değişiklik yapması gerekecek. Burada ödediğimiz maliyeti herkes görebilir; artık iki kat daha fazla kodumuz var ve A1 ve A2 için geçerli olan hata düzeltmeleri her ikisi için de geçerli olmalıdır. Çoklu depodaki dallanma yaklaşımıyla bu, kiraz toplamanın arkasına gizlenir. Tekrarlama olmadığından maliyetin daha düşük olduğunu düşünüyoruz. Pratik açıdan bakıldığında maliyet aynıdır: Büyük ölçüde birbirinin aynı olan iki kod tabanını oluşturacak, yayınlayacak ve birini silene kadar sürdüreceksiniz. Aradaki fark, tek depoda bu acının doğrudan ve görünür olmasıdır. Bu daha da kötü ve bu iyi.

Nihayet üçüncü noktaya geldik. Serbest bırakma gecikmesi. A tarafından yapılan değişikliklerin A Takımının hayatlarını iyileştirmesi mümkündür. Önemli, ancak acil değil. Sadece erteleyebilir miyiz? Bir çoklu depoda, eseri sabitlemek için bunu iteriz. Tabii bunu D Takımına da söylüyoruz. Yetişene kadar eski versiyonda kalın! Bu seni korkak rolü oynamaya hazırlıyor. A Takımı, D Takımının giderek güncelliğini yitiren bir sürüm kullandığı gerçeğini göz ardı ederek kendi bileşeni üzerinde çalışmaya devam ediyor (bu, D Takımının sorunu, onlar aptal). Bu arada, D Takımı, A Takımının kod istikrarına yönelik dikkatsiz tutumu hakkında, eğer bu konuda konuşurlarsa, yetersiz konuşuyor. Aylar geçiyor. Sonunda D Takımı bir güncelleme olasılığına bakmaya karar verir, ancak A'nın elinde yalnızca daha fazla değişiklik vardır. A Takımı, D'yi ne zaman ve nasıl kırdığını zar zor hatırlıyor. Yükseltme daha acı verici ve daha uzun sürecek. Bu da onu öncelik yığınının daha aşağısına gönderiyor. Ta ki A'da bizi şube yapmaya zorlayan bir güvenlik sorunu yaşadığımız güne kadar. A Takımı zamanda geriye gitmeli, D'nin stabil olduğu bir nokta bulmalı, sorunu orada çözmeli ve serbest bırakılmaya hazır hale getirmelidir. Bu, insanların yaptığı fiili seçimdir ve açık ara en kötüsüdür. Birbirimizi görmezden gelebildiğimiz sürece hem A Takımı hem de D Takımı için iyi olacak gibi görünüyor.

Tek depoda üçüncü gerçekten bir seçenek değildir. Durumla iki yoldan biriyle başa çıkmak zorunda kalırsınız. İki sürüm şubesine sahip olmanın maliyetlerini görmeniz gerekir. Geriye dönük uyumluluğu bozan güncellemelerden kendinizi korumayı öğrenin. Ama en önemlisi: zor bir konuşma yapmaktan kaçınamazsınız.

Tecrübelerime göre takımlar büyüdüğünde artık tüm sistemi akılda tutmak mümkün olmuyor ve bu en önemli kısım. Sistemdeki discord görünürlüğünü arttırmalısınız. Ekiplerin kendi bileşenlerinden uzaklaşıp diğer ekiplerin ve tüketicilerin çalışmalarına bakmasını sağlamak için aktif olarak çalışmalısınız.

Evet, çoklu depo sorununu çözmeye çalışan araçlar oluşturabilirsiniz. Ancak büyük kuruluşlarda sürekli teslimat ve otomasyona ilişkin deneyimim bana şunu söylüyor: Ek araçlar kullanılmadan varsayılan davranış, görmeyi beklediğiniz davranıştır. Bir çoklu havuzun varsayılan davranışı izolasyondur, bütün mesele budur. Bir monorepository'nin varsayılan davranışı paylaşılan sorumluluk ve şeffaflıktır, bütün mesele budur. Her iki durumda da pürüzlü kenarları düzeltecek bir araç yaratacağım. Bir lider olarak her zaman bir tek depo seçeceğim çünkü araçların istediğim kültürü güçlendirmesi gerekiyor ve kültür küçük kararlardan ve ekibin günlük çalışmalarından geliyor.

Ankete sadece kayıtlı kullanıcılar katılabilir. Giriş yapLütfen.

En büyük fanatikler kimler? Destekçiler:

• Monorepo

• Rust

• Yanlış anket / her ikisi

33 kullanıcı oy kullandı. 13 kişi çekimser kaldı.

Kaynak: habr.com