Dal tabanlı versiyon için, yapılandırma yönetim sürecinin panoramasını mükemmel şekilde gösteren aşağıdaki diyagramdan bahsetmemiz gerekiyor. Öncelikle, bu diyagram Git modeline dayanarak yazılmıştır, ancak aslında Git ve Subversion sürüm kontrol yönetimi kavramını çözmüş durumda, ancak Git şube yönetimi ve dağıtık performansta Subversion'a göre niteliksel olarak ileri bir sıçrama yapıyor (ancak bu makalenin odağı bu değil).
Bu grafiğin prensibini tanıtmadan önce, genel sürüm kontrolü için iki farklı stratejiden bahsedelim; biri "öncü omurga, kararlı dal", diğeri ise "kararlı omurga, öncü dal". Adından da anlaşılacağı gibi, bu sistem gövdede veya şubede olan stabil versiyondur (üretim versiyonu). VSS kullanan geleneksel proje ekiplerinde hangi moda ait olduğunu söylemek zordur, çünkü VSS'nin kendisi bir şube yönetim stratejisi yoktur, bu yüzden birçok proje ekibi üretim ortamı ve geliştirme ortamına karşılık gelen iki (veya üç) versiyon kütüphanesi oluşturur; tabii ki bu da gizli bir şube yönetimidir. Ancak, sürüm kontrol aracı olarak Subversion veya Git'e geçerseniz, çoğu takım stabil trunk modu kullanır; yani trunk (kamyon veya master) kararlı bir üretim ortamına karşılık gelir ve üretim sürümünü belirtmek için farklı sürümleri etiketler. Kişisel olarak, stabil omurga kodu deseninin şu anda kesinlikle ana akım kod sürüm kontrol yönetimi çözümü olması gerektiğini düşünüyorum. Yukarıdaki resim, standart "stabil omurga" yönetim modelidir.
usta: İlgili Subversion kamyon。 Prodüksiyon versiyonuna karşılık olarak, her sürümde bir kez etiketleniyor.
Sürüm Dalı (Entegrasyon Dalı olarak da bilinir): Üretim güncellendiği sürece, önce sürüm dalı (entegrasyon dalı) ile birleştirilmelidir. Bu, proje ekibinin şu anda "ön prodüksiyon" ve "simüle edilmiş ortam" kavramlarına biraz benziyor.
Dal Geliştirme (Dev Branch veya Dev Branch): Geliştirme ortamının karşılaştığı ortam.
Özellik Dalı (Özellik Dalı): Bazı bağımsız fonksiyonlar ayrı bir geliştirme dalından ayrılabilir. Bu durum, bazı özelliklerin güncellenmesinin nispeten uzun sürebileceği gerçeğini ele almak için, böylece sürüm ve ayrı dallar düşürülmemek için.
Hotfixes Branch (Hata Düzeltme Dalı): Buradaki hata esas olarak üretim hatasıdır.
Gövde ve dalları tanıttıktan sonra, bu dalların oluşumu ve birleşme yönünü tanıtmam gerekiyor.
Master, üretim sürümüdür ve trunk sadece iki dal birleştirme için kabul eder; biri sürüm dalı (entegrasyon dalı), diğeri ise hotfixes dalıdır. Başka hiçbir dal üretim şubesine birleştirilemez.
Yayın dalı, üretim ile aynı zamanda oluşturulur, bu da üretimle tamamen aynıdır. Sadece geliştirme dalının onunla birleşmesini kabul ediyor. Başka bir deyişle, doğrudan özellik dalından veya hata düzeltme dalından birleştirmeyi kabul etmez.
Geliştirme dalı, geliştirme dalı, entegrasyon dalı gibi, belirli bir zamanda üretim ortamıyla aynıdır. Ancak geliştirme ilerledikçe, geliştirme dalında yeni özellikler oluşturulmaya devam edecek. Dev Theory sadece iki dalın birleştirilmesini kabul eder; biri hotfixes, diğeri ise özellik dalıdır.
özellik dalı, belirli bir noktadan (sürümden) dev branch ile başlayarak, feature dal sonunda dev branch ile birleşir.
Sürüm kontrol yöntemini kısaca bir senaryo şeklinde tanıtalım
Diyelim ki bir üretim sürümü dallara bölünür (dev, hotfixes, release) ve bu sırada dev toplamda on fonksiyon geliştirmeye başlar. 10 özellikten 8'i geliştirildiğinde, test ekibi dahili test için müdahale etmeye başladı ve yapılandırma yöneticisi, dev branch'ı dev ortamına entegre ederek sürekli entegrasyon araçları aracılığıyla test yaptı (burada ayrı bir konu). Test doğrulaması, basit sigorta sigortası ve hasar iadesi gibi iki fonksiyonun tamamen kabul edilemez ve yeniden yapılması gerektiğini ortaya koyduğunda, basit sigorta sigortası ve hasar iadesi gibi iki özellik dalı dev'den ayrıldı ve dev kolunda ilgili kodun da geri alınması gerekiyordu (burada manuel işlemler). Test ekibi, dev branch testinde bir sorun olmadığını tespit ettiğinde, UAT koşullarını karşılar; bu nedenle yapılandırma yöneticisi dev branch'ı release branch'a birleştirir ve ardından sürekli entegrasyon araçlarıyla bu dalı pre-prodüksiyon ortamına yayımlayıp kullanıcıya test için teslim eder. Kullanıcı doğrulaması bir sorun bulduğunda, geliştirici geliştirme dalını değiştirir ve sonra onu sürüm dalına birleştirir (burada, orijinal resimde, doğrudan sürüm dalında değiştirilmiştir, bence bu iyi değil, geliştiricinin sadece geliştirici dalıyla yüzleşmesini öneririm), doğrulama sürüm doğrulama süreci derhal derleme ortamında ciddi bir hata olduğunu fark ettiğinde, bu hata hız düzeltmeleri dalında acil şekilde değiştirilir ve doğru olduğu doğrulandıktan sonra acil olarak başlatılır. Aynı zamanda, hotfixes dalı dev ile birleştirilir (burada çoğunlukla manuel olarak kullanılır, çünkü bu dönemde üretim sürümü dev sürümünden çok farklı ve otomatik birleştirmeyi tamamlamak genellikle imkansızdır), ardından dev sürümüne birleştirilir. Bir süre sonra, talep iade fonksiyonu artık gerekmeyebilir ve iptal edilmesi gerekir, bu yüzden talep iade özelliği dalı silinir. Bir diğer özellik ise kolayca güvence altına alınıyor ve geliştirilip bir sonraki çevrimiçi sürümle birlikte tekrar geliştirilip geliştirildi.
Yukarıdaki senaryo temel olarak günlük geliştirme sürecinde rutin geliştirme, paket açma, acil durum güncellemeleri ve diğer senaryoları içerir.
|
Yayınlandı 8.04.2018 10:25:39
|
|
|
|
