Ağır şirket haberleşmeleri, yapılandırma yönetimi ve test gereksinimlerine sahip Mercurial Depo yapısı

Ben dağıtılmış versiyon kontrolü Tao'da kendimi yeniden eğitmek için mücadele eden başka bir Subversion kullanıcısıyım.

Subversion'u kullanırken, projenin önemsiz yaklaşımının büyük bir hayranıydım ve eski işverenlerimin çoğuyla depo şubelerimizi yapılandıracağız; etiketler ve gövde aşağıdaki gibi:

branches-+
         +-personal-+
         |          +-alice-+
         |          |       +-shinyNewFeature
         |          |       +-AUTOMATED-+
         |          |                   +-shinyNewFeature
         |          +-bob-+
         |                +-AUTOMATED-+
         |                            +-bespokeCustomerProject
         +-project-+
                   +-shinyNewFeature
                   +-fixStinkyBug
tags-+
     +-m20110401_releaseCandidate_0_1
     +-m20110505_release_0_1
     +-m20110602_milestone
trunk

Gerçek kaynak ağacın içinde, aşağıdaki yapıyı kullanırdık (şöyle bir şey):

  (src)-+
        +-developmentAutomation-+
        |                       +-testAutomation
        |                       +-deploymentAutomation
        |                       +-docGeneration
        |                       +-staticAnalysis
        |                       +-systemTest
        |                       +-performanceMeasurement
        |                       +-configurationManagement
        |                       +-utilities
        +-libraries-+
        |           +-log-+
        |           |     +-build
        |           |     +-doc
        |           |     +-test
        |           +-statistics-+
        |           |            +-build
        |           |            +-doc
        |           |            +-test
        |           +-charting-+
        |           |          +-build
        |           |          +-doc
        |           |          +-test
        |           +-distributedComputing-+
        |           |                      +-build
        |           |                      +-doc
        |           |                      +-test
        |           +-widgets-+
        |                     +-build
        |                     +-doc
        |                     +-test
        +-productLines-+
        |              +-flagshipProduct-+
        |              |                 +-coolFeature
        |              |                 +-anotherCoolFeature
        |              |                 +-build
        |              |                 +-doc
        |              |                 +-test
        |              +-coolNewProduct
        +-project-+
                  +-bigImportantCustomer-+
                  |                      +-bespokeProjectOne
                  |                      +-bespokeProjectTwo
                  +-anotherImportantCustomer-+
                                             +-anotherBespokeProject

Fikir, mühendislik ekibi arasındaki iletişimi yapılandırmaya yardımcı olmak için havuzun yapısını kullanmaktı (ve hala da öyleydi); işletmenin müşteriye dönük kısmı ve diğer çeşitli paydaşlar ve alan uzmanları.

Görmek için: "Proje" dizinlerinden birinde yer alan kaynak belgeler sadece bir kez kullanılır (ve para kazanır). "ProductLines" dizinlerinden birinde yer alan dokümanlar, söz konusu satırdaki bir ürünün satıldığı kadar para kazanır. "Kütüphaneler" dizinlerinden birinde yer alan dokümanlar, bunları kullanan ürünlerin satıldığı kadar çok para kazanır.

Maliyetlerin amortisman kavramını açık hale getirir ve işletme genelinde kaynak belgenin yeniden kullanımı için destek oluşturulmasına yardımcı olur.

Ayrıca, yapı otomasyon araçlarımızın üzerinde çalışabileceği ortak bir yapı olduğu anlamına gelir. (Derleme komut dosyalarımız, her bir bileşenin nasıl oluşturulacağını belirten yapılandırma dosyalarını buldukları "derleme" klasörlerini arayan kaynak ağacında yürür; belge oluşturma ve test için de benzer bir işlem gerçekleşir).

Önemli olarak, üzerinde çalıştığım ürünlerin performans ölçüm ve karakterizasyon testlerini yürütmesi genellikle UZUN zaman alır; 20 ila 200 saat; birkaç GB ila birkaç TB arasında işlenmiş test sonuçları / ara veri (bir yerde saklanması ve belirli bir sistem yapılandırmasına bağlı olması gerekir; böylece zaman içindeki performans artışı ölçülebilir). Bu sorun, yapılandırma yönetimini önemli bir husus haline getirir ve aynı zamanda, tipik olarak performans ölçümü ve karakterizasyon testlerini çalıştırmak için gereken hesaplama kaynakları sınırlı olduğundan, merkezileşme için bazı gereksinimler getirir; (64-128 çekirdekli küçük bir küme).

Son bir not olarak; sürekli entegrasyon sistemi bir yapıyı tetiklemesi gerektiğini bilir; statik analiz; duman testi ve birim test çalıştırması her gövde değişikliğinde, her "etiket" dalı her değiştiğinde ve her "OTOMATİK" dal dalı her değiştirildiğinde. Bu şekilde, bireysel geliştiriciler CI sistemini kendi kişisel şubeleri olan önemli bir yetenek olan IMHO ile kullanabilirler.

Şimdi, sorum şu: Yukarıdakilerin tümünü Mercurial ile nasıl çoğaltabilirim (ve mümkünse geliştirebilirim).

--Düzenle:

Şu andaki düşünme şeklim, merkezi bir Subversion Deposu kullanmak, genel yapıyı tanımlamak, ancak hg'nin bir istemci olarak kullanılmasına izin vermek, böylece geliştiricilerin yerel olarak depolara sahip olmasını sağlamaktır.

Spoike'ın Cevabı mükemmel, ancak yorum için çok büyük olan eklemeye değer olacağını düşündüğüm birkaç şey var.

Şube organizasyonu

Mercurial ile ilk organizasyon şemanızın tamamını göz ardı edebilirsiniz. Spoke'un dediği gibi, her deponun kendi etiketleri, dalları (adlandırılmış ve anonim) vardır ve iş ihtiyacına göre düzenlenebilir.

Kütüphanenin bespokeProjectTwoözel bir sürümüne ihtiyaç duyarsanız charting, o zaman dallar charting, yeni tesisleri ekler ve içinde kullanırsınız bespokeProjectTwo. Yeni tesisler (ve hataları) standart chartingkütüphaneye atıfta bulunacak diğer projeler tarafından kullanılmayacaktır . Ana chartingkitaplıkta hatalar düzeltildiyse, bu değişiklikleri dalda birleştirebilirsiniz. Diğer projeler de bu tesislere ihtiyaç duyduysa, bu projeleri özel şubeyi kullanmalarını sağlayabilir veya şubeyi ana hatta birleştirip şubeyi kapatabilirsiniz.

Ayrıca, OTOMASYON şubeleriniz gibi belirli tesisleri sağlamak için şube adlarını yapılandırmak için bir politikaya sahip olmanızı engelleyen hiçbir şey yoktur.

Dizin organizasyonu

Kaynak dizininizi tam olarak Mercurial'da olduğu gibi tutamamanızın bir nedeni yoktur. Tek fark, Subversion ile tek bir monolitik (src)deponuz olmasına rağmen , Mercurial ile mantıksal olarak gruplandırılmış depolara ayrılmanız daha iyi. Kaynak ağaç yapınızdan, muhtemelen aşağıdakilerin her birini ayrı depolar olarak çıkaracağım:

src-+
      +-(developmentAutomation)
      +-libraries-+
      |           +-(log)
      |           +-(statistics)
      |           +-(charting)
      |           +-(distributedComputing)
      |           +-(widgets)
      +-productLines-+
      |              +-(flagshipProduct)
      |              +-(coolNewProduct)
      +-project-+
                +-bigImportantCustomer-+
                |                      +-(bespokeProjectOne)
                |                      +-(bespokeProjectTwo)
                +-anotherImportantCustomer-+
                                           +-(anotherBespokeProject)

Bu, herhangi bir ürün veya ısmarlama projenin herhangi bir revizyonda herhangi bir kütüphane kombinasyonunu kullanmasına izin verir . Göz at cıva alt depoları , bir ürünün veya projenin herhangi bir sürümü için kullanılan hangi kütüphaneleri yönetmek için kolay bir yol.

İş Akışı

Spoike'ın önerilen iş akışına bir alternatif (geliştirici kutsanmış repodan çeker, yerel olarak çalışır, bir çekme isteği gönderir ve son olarak entegratör bu değişiklikleri çeker ve birleştirir) sürekli entegrasyon sistemini bir aracı olarak kullanmak olacaktır.

Daha önce olduğu gibi, geliştirici mübarek repodan çekiyor ve yerel olarak çalışıyor, ancak bittiğinde, mübarek repodan tekrar çekiyor ve mübarek bir repoya itmeden önce kendilerini birleştiriyorlar. Mübarek repoda yapılan değişiklikler daha sonra gözden geçirilir (manuel veya otomatik olarak) ve sadece onaylanırlarsa mübarek repoya taşınır.

Bu, birleştiricinin bir değişikliği değil, yalnızca bir değişikliği kabul ettiği veya reddettiği anlamına gelir. ^{Benim tecrübelerime göre, birleştirme yapmak için kod yazan geliştirici, başkasının yapması için olduğundan neredeyse her zaman daha iyidir.}

Mercurial kitapta önerildiği gibi, kancalar bu prosedürü otomatikleştirmek için kullanılabilir:

Birisi herkesin aldığı sunucuya bir değişiklik kümesi ittiğinde, sunucu değişiklik kümesini kalıcı olarak kabul etmeden önce test eder ve test paketini geçemezse reddeder. Kişiler yalnızca bu filtreleme sunucusundan değişiklik yaparsa, insanların çektiği tüm değişikliklerin otomatik olarak denetlenmesini sağlar.

Diğer sorunlar

Büyük test veri kümeleri sorunu, bu test verilerinin bir cıva alt deposuna yerleştirilmesiyle de çözülebilir . Bu, kod deposunun test verileriyle şişirilmesini önlerken test verilerini yine de revizyon kontrolü altında tutar.

Tamam, bunu basitçe cevaplamaya çalışıyorum.

Ne bilmek istiyorsun

Bilmeniz gereken ilk şey: Mercurial, dağıtılmış sürüm kontrolüdür ve aşağıda listelenmesi gereken bazı özelliklere sahiptir.

• Kaynak bu havuzun klonlanabileceği bir depodan gelir. Tüm klonlanmış depolar, senkronizasyon yoluyla (erişim kısıtlamalı çekme ve itme komutlarıyla) kodu birbirleriyle paylaşabilir.
• Kodun bir kopyası olan her kullanıcının havuzun bir kopyası vardır. Dallanmak istiyorlarsa, yerel klonlarında yapabilirler. Bu, her kullanıcının nasıl dallanması gerektiğini düzenlemenize gerek olmadığı anlamına gelir. Bunu kendileri için yapabilirler.
• Etiketler, bir taahhüt (cıva'daki sabit etiketlerle aynıdır) tarafından mercurial olarak oluşturulur. Bu, etiketler için depo yapınızın içinde bir dizine ihtiyacınız olmadığı anlamına gelir.

• İnsanların DVCS'de (github ve bitbucket'te kullanılan) çalıştığı genel model, bunu yarı merkezi hale getirmektir.

  Her kullanıcının bir genel deposu (bazı paylaşımlarda veya güvenli bir sunucuda) ve özel bir deposu (kendi iş istasyonlarında) vardır. Her ikisi de bir entegratörün "kutsanmış" deposunun klonlarıdır. Kodlarını yayınlamaya hazır olduklarını hissettiklerinde, değişiklikleri herkese açık depolarına gönderebilirler. Bir entegratör daha sonra hangi kullanıcıların kodu "kutsanmış" depoya çekeceğini seçebilir.

  Entegratör bazı kullanıcıların kodlarını kolayca birleştiremezse, değişiklikler reddedilir ve depolarını güncellemek ve birleştirmeyi kendileri düzeltmek o kullanıcıya bağlıdır. Sıklıkla birleştirirseniz (birleştirilmesi gereken daha az kod olduğu için) genellikle bu kadar zor değildir ve genellikle kullanıcı birleştirme ile ilgili neyin yanlış gittiğini bilmelidir.

Proje başına havuz kurulumu

Yani her zamanki kurulum, her proje için aşağıdakilerin olmasıdır:

• Entegratörün sorumlu olduğu, salt okunur bir genel veri havuzu. "Kutsanmış".

  Yani tüm kullanıcılar içeriği çekebilir / getirebilir ancak içeri itmek için erişimi yoktur.

• Her kullanıcı havuzun kendi genel klonuna sahip olabilir.

  En kolay bir paylaşım sürücüsüne koymak olarak kurulmuş (ancak bitbucket gibi barındırma düşünebilirsiniz). Entegratör, kullanıcılardan çekme istekleri alır ve bu depolardan yeni kodu almaya çalışır. Birleştirme sorunsuz bir şekilde yapıldığında, salt okunur depoya konur. Değilse, kullanıcılardan yerel olarak kendileri için güncelleme ve birleştirme yoluyla ortaya çıkan birleştirme çakışmalarını düzeltmeleri istenir.

• Her kullanıcının kendi özel depo klonları olabilir.

  İyi uygulama, kamusal klonlarından çekmektir, ancak halklarından mı yoksa entegratörlerinden mi çekildikleri önemli değildir. Tüm taahhütler benzersiz bir şekilde tanımlanabilir, bu nedenle halka açık bir şekilde getirmeyi unuttuğunuz birleştirme taahhütleri düzeltmek nispeten kolaydır (özel değişikliklerden halka iterek, otomatik olarak entegratörün değişikliklerini de alır).

Kaynak kodu organizasyonu

Proje kaynağının nasıl düzenleneceği gibi, düşünmeniz gereken bir şeydir. Bir yapının kaynak kontrolüne ihtiyacı varsa, onu kaynak kontrolüne koyun. Şahsen, ikili dosyalar veya günlük dosyaları gibi derleme veya çalışma zamanı (bu tür eserler üzerinde birleştirme çakışmaları riskinin yüksek olması nedeniyle) tarafından yapılan yapay nesneleri kontrol etme fikrinden hoşlanmıyorum.

Ayrıca, geliştiricilerin devam etmesini kolaylaştırdığı ve sürümler veya canlı / üretim ortamı (uygulama / web sunucusu ayarları gibi) için yapılandırmayı bozmadıkları sürece yapılandırmayı da kontrol edebilirsiniz. Bu, yapılandırmanın kodu geliştirdikten sonra beş dakika içinde geliştiricilere başlamak için ciddi bir şekilde engellemesi durumunda yeniden düzenlenmesi gerektiği fikrine yol açar. Diğer bir gereklilik ise geliştiricilerin sürümü veya canlı / üretim ortamını bozmasının zor olması gerektiğidir.

Kodun bazı sürümlerine bağlanması gereken test verileriniz olduğunu belirtiyorsunuz. Mercurial ve Git gibi DVCS sistemlerinin BÜYÜK verileri kontrol ettiğinizde yavaşlama eğilimi gösterdiği için bu biraz daha zorlayıcı. Deneyimlerime göre, 5 GB ikili dosyalardan sonra gerçekten dayanılmaz hale geliyor (milajınız değişebilir, bu yüzden sizin için nasıl çalıştığını test etmelisiniz). Bununla birlikte, oluşturulan verileri kendi havuzuna koymanızı ve bunları test ederken bunları uygun şekilde etiketlemenizi (ve / veya aynı meta veri amaçları için metin dosyaları oluşturmanızı) öneririm.

Umarım bunların hepsi mantıklıdır. Bazı ayrıntıları kaçırdıysam veya bir şeyin daha fazla açıklanması gerekiyorsa lütfen düzenlemeye devam edeceğim.