Kodumuzu yeniden kullanılabilir bitlere böldükten sonra nasıl test edip dağıtırız?

Bir geliştirici ve tüm kodumuzu içeren bir svn repo ile başladık:

^/foo/trunk/module-a
^/foo/trunk/module-b
^/foo/trunk/module-b/submodule-b1
^/foo/trunk/website1

(o zaman bu büyük bir gelişmeydi). Bu, biraz büyümek için bir şans elde ettikten sonra, dairesel bağımlılıklar, yavaş testisler ve kodu yeniden kullanmanın genel zorlukları ile ilgili sorunlar yaşamaya başladık (çünkü web sitesi1'in özellik seti başka bir şekilde genel modül-a'ya girdi).

Kod tabanını modülerleştirmek ve kısa bir süre içinde git'e gitmemizi beklemek (ve git'in svn mega-repos'u sevmediği bir yerde okumak), çok daha ayrıntılı bir yapıya geçtik:

^/module-a/trunk/
^/module-b/trunk/
^/module-b/trunk/sumbmodule-b1
^/earlier-sub-sub-sub-module-c/trunk
etc. (about 120 such modules)

Bu kavramsal olarak harikaydı. Daha modüler kod, çok daha hızlı test paketleri, belgelenmesi daha kolay, vb. Daha genel bileşenlerimizin bazılarını açık kaynaklı hale getirdik ve tüm modülleri pip olarak takılabilir hale getirdik ( pip install -e .bunları developmentvirtualenv'e kurmak için kullanarak ).

Çalışma ^/srv/trunkzamanı ortamının klasör yapısını içeren bir havuz oluşturduk , yani. ^/srv/trunk/libmodüller, /srv/trunk/srckalıntılar ^/foo/trunk, ^/srv/trunk/wwwweb siteleri vb.

Ve son olarak (çok uzun zaman önce çalıştığım performanstan bir fikir alarak [ https://www.perforce.com/perforce/r12.1/manuals/cmdref/client.html] ) bir "vcs- ilgili tüm depoları listeleyen ve bunların geliştirici ortamına nereden kontrol edilmesi gerektiğini gösteren metin dosyasını ve buna karşılık gelen bir komutu getir. Örneğin, bir vcs-fetc satırı:

svn srv/lib/module-a ^/module-a/trunk

neden olur (ilk kez)

cd /srv/lib && svn co ^/module-a/trunk module-a

veya (daha sonra)

cd /srv/lib/module-a && svn up

ve benzer şekilde github depoları için (hem kendi hem de değiştirilmiş / değiştirilmemiş satıcı paketlerimiz).

Üretim ortamını oluşturmak için aynı vcs-fetch işlemini kullandık, ancak bir vcs-fetch yaptıktan sonra hangi sürümün prod'da çalıştırıldığını bilmemizin bir yolu olmadığını çabucak öğreniyoruz.

Mega repo ile, sadece bagajdan eşyayı güncellemeden önce revizyon numarasını not edebiliriz ve geri dönmek basit bir svn -r nnn up .uzaktı. Hem svn hem de git kodunda (ve hg'de bir modül) ve ~ 120 depolarında, bunun nasıl yapılacağı açık değildir.

Bugün http://12factor.net/ okudum ve ilk faktör "Bir kod temeli" olduğunu, bu yüzden de burada doğru yoldan uzakta olup olmadığını merak ediyorum?

Benim bir fikrim pip-kurulabilir "dağıtım" tekerlekler oluşturacak bir dağıtım komut dosyası oluşturmak ve bunları bir requirements.txtdosyada "paket" oldu . Bir dağıtım daha sonra yeni bir virtualenv oluşturmayı, dağıtım tekerleklerini listeleyen gereksinimler.txt dosyasını oluşturmayı ve etkin virtualenv'i değiştirmeyi içerir. Bir öncekine geri dönmek sadece virtualenv'i geri çevirmeyi içerecekti (ancak biz sanalenleri sonsuza dek tutmak istemezsek, zaman içinde herhangi bir noktaya geri dönmemize izin vermezdi - daha önce hiç ihtiyaç duyulmamış deneyimlerime göre).

Bu noktada yanlış yönde yürüyüp yürümediğimi ya da doğru yolda yeterince yürümediğimi merak ediyorum ..? (okuduğum her şey "uygulamanız" hakkında konuşmaya devam ediyor ve bunun aynı kod tabanından 14 web sitesi çalıştırmaya nasıl dönüştüğünü bilmiyorum ...)

Şubeleri (veya 'etiketleri' veya 'serbest bırakma' dallarını) kaçırdığınız anlaşılıyor.

Hangi sürümü yüklediğinizi belirlemek için SVN revnum'unuzu referans olarak kullanmak yerine, yayımlanan revizyonda bir şube oluşturmanız gerekir. Daha sonra bu şube adını dağıtırsınız.

Hiçbir değişiklik olmasa bile dallanmayı kolaylaştırır, böylece her modül aynı sürüm numarasını korur, ancak OSS paketleriniz hiçbir değişiklik olmadan dallanmaktan hoşlanmayabilir, bu nedenle bir sonraki en iyi şey bağımlılıkların bir komut dosyasını tutmaktır - yani sürüm 5 ürününüzün OSS modülü X v2 vb.

Komut dosyanızı sürümlere başvurmayı durdurmak ve bunun yerine şube adlarıyla çalışmak için değiştirirsiniz (her ne kadar bir şey olsa da, sabit bir adlandırma kuralına karar vermek en iyisidir, örneğin Release_1_2_3)

Başka bir ipucu, her bir modülün mevcut sürümü açıklayan bir dosyayı korumaktır, gerekirse bunları otomatik olarak oluşturabilir ve belki de tam bir değişiklik günlüğü ekleyebilirsiniz, ancak bu, herkesin hangi sürümün sadece bakarak konuşlandığını görebileceği anlamına gelir.

Sanırım zaten birçok iyi fikriniz var, bunların çoğunu yıllar boyunca çeşitli projelerde kullandım ve birincil endişeniz, bölündüğünüzde belirli bir pakete dahil olan tüm modüllerin hangi sürümünün söylenemediği gibi görünüyor. onları.

Bunları, özellikle de Ext3h'den bahsedildiği gibi, özellikle birden fazla ekibiniz ve değişken sürüm döngüleriniz varsa, belirli bir ayrıntı düzeyinde bölmek için kullanıyorum.

Modüllerinizin ne kadar izole olduğundan veya sürümlemenizin ne kadar ayrıntılı olmasını istediğinizden emin olmadığım için bazı seçenekler önereceğim.

Git alt modüllerini kullanın. Alt modüllerle, her modülü svn kurulumunuza ve aynı zamanda ne düşündüğünüze benzer ayrı bir git deposunda saklayabilirsiniz. Daha sonra bu modülleri, her bir alt modülün kendi taahhütlerinin her biri için ilgili taahhüdüne bir referans içerecek olan kök projeye bağlarsınız.

IMO bu teorik olarak güzel bir kurulum ve oldukça basit. Ana dezavantajları, alt modüller için iş akışının biraz garip olmasıdır, ancak daha önce komut dosyalarıyla bu tür şeyleri güzel bir şekilde çözmüş gibisiniz, bu yüzden gerçek bir sorun olmayabilir.

Diğer uyarı, alt modül taahhüt referanslarının sadece bir SHA1 olması, hangi dalda olduğunuzu asla insan tarafından okunabilir herhangi bir ayrıntı olmaması ve doğrudan alt modülde çalışmak istediğinizde doğru dalı manuel olarak kontrol etmeniz gerekebilir.

Ancak, bu kalıbı çok fazla kullanmadım, bu nedenle sizinki gibi büyük bir proje için ne kadar problem olabileceğini bilmiyorum.

Başka bir alternatif de bir çeşit bağımlılık yöneticisi kullanmaktır. Bu, her modülün veya modül grubunun ayrı ayrı sürümlendirilmesini, paketlenmesini ve yayınlanmasını ve bu paketleri istediğiniz zaman istediğiniz şekilde bir araya getirebilecek bir sisteminizin olmasını gerektirir.

Pip'i zaten öneriyorsunuz ve önerinizde eksik görünen şey, ortaya çıkan gereksinimleri.txt'yi derlemeyle birlikte veya kök proje deposunda saklamaktır, böylece kaydetmek zorunda kalmak yerine sanalenv'i daha sonra yeniden oluşturabilirsiniz disk üzerinde.

Başka sistemler de var; Apache Ivy'nin biraz özelleştirilmiş bir sürümünü kullanarak her modülü paketleyip yayınlamanın yanı sıra son proje için bir araya getirerek oldukça büyük bir proje kurdum. Ayrıca, kurulumu daha sonra yeniden oluşturmanız gerekirse, referans verdiğiniz tüm modüllerin tüm sürümlerini listeleyen bir bildirim de saklar.