Bir üretim şubeniz mi yoksa master mı kullanıyorsunuz?

Bir Railsuygulama üzerinde diğer uzaktan geliştiricilerle küçük ekip üzerinde çalışıyorum . gitİş akışımızı değiştirmeye başlıyoruz . Aşağıdaki gibi bir dallanma yapısını düşündük:

(dev) -> (qa) -> (stag) -> (master)

Ancak bazı geliştiriciler, ustalıkla üretime otomatik olarak geçebilecek yeni geliştiriciler için daha az kafa karıştırıcı olabileceğini düşündü. Bunun yerine herkesin ustalıkla çalışmasını ve üretim için ayrı bir dal oluşturmasını düşündüler.

(master) -> (qa) -> (stag) -> (prod)

Usta konuşlandırılabilir tutmak ve geliştirme olarak kullanmak istemediğiniz öğretildi ve usta çalıştığım önceki yerlerden her zaman üretim için konuşlandırılabilir olması gerekiyordu.

Master'ın geliştirme için aktif olarak kullanıldığı bir dallanma yapısı kullanmanın dezavantajları nelerdir ve ayrı bir ürün dalı dağıtımlar için kullandığınız şeydir?

Bu yaklaşımın herhangi bir avantajı veya dezavantajı yoktur. Bunun basit olduğunu söylememin sebebi: Git için, master'dan geliştirirseniz veya master'dan serbest bırakırsanız fark etmez. Dalları serbest bırakmanıza bile gerek yok; isteğe bağlı bir taahhüdü etiketleyebilir ve bunun yerine serbest bırakabilirsiniz.

Gerçek sorun burada süreç ve prosedür biridir. Bir şekilde yapmanın daha yeni geliştiricilerin kafasını karıştıracağından endişelenen daha üst düzey geliştiriciler, sürüm modelinin ne olduğunu ve neden bu şekilde olduğunu açıklamak için zaman yatırmaya hazırlanmalıdır.

Herkes ustanın gelişim için olduğunu ve diğer bazı keyfi dalların sürümler için olduğunu ve bunu sürdürme işi yapıldığını anladığı sürece , bu yaklaşımla ilgili herhangi bir sorun olmamalıdır.

İkileminizi görebiliyorum. Üstat hakkında her zaman ne varsaydığımı öğrenene kadar bende vardı.

Usta konuşlandırılabilir tutmak ve geliştirme olarak kullanmak istemediğiniz öğretildi ve usta çalıştığım önceki yerlerden her zaman üretim için konuşlandırılabilir olması gerekiyordu.

Git'in belgelerinden / kitabından - Git branching

Git'teki “ana” dal özel bir dal değildir. Tıpkı diğer dallar gibi. Hemen hemen her havuzun tek nedeni, git init komutunun varsayılan olarak oluşturması ve çoğu insanın onu değiştirmek için uğraşmamasıdır.

Yani, tercih edilen bir iş akışınız varsa ve onunla çalışmak zorsa, çünkü takımdaki farklı geliştiricilerin farklı fikirleri var master. Aşağıdaki gibi bir iş akışı mastersöylemek prodve kullanmak için yeniden adlandırmayı düşünebilirsiniz -

(dev) -> (qa) -> (stag) -> (prod)

Ana dal adını nasıl değiştireceğiniz aşağıda açıklanmıştır .

masterŞube adını değiştirmeniz gerektiğini söylemiyorum . Ancak, tercih edilen bir iş akışınız varsa ve masterşube adını değiştirmeye yardımcı oluyorsa , bunu elbette yapın :-)

Bu durumda sözleşmeleri kontrol etmeyi tercih ederim. Her takım, yeni özellikleri başlatma konusunda daha iyi olan üyeleri ve bir sürüm için işleri stabilize etme konusunda daha iyi olan kişileri içerir.

İkincisi yoksa, kod incelemeleri yardımcı olacaktır (genellikle, daha disiplinli insanlar yine de kod incelemelerini isteyecektir).

Bu yüzden Git repo'mızı (Gitlab kullanıyoruz) yalnızca belirli kişilerin çekme isteklerini birleştirebileceği ve her geliştiricinin ana repo için kendi özel çatalını alacağı şekilde yapılandırıyoruz.

Bu iki sorunu çözer:

1. Yeni geliştiriciler yanlış şubeyi değiştiremezler (çünkü çalışmalarını doğrudan ana repoya itemezler). Onlar için itmek olabilir masterkendi repo ancak çekme isteği geldiğinde o düzeltilecektir.

2. Kod sözleşmeleri, her taahhüt kendi görüşlerini ve bilgilerini getiren en az başka bir kişi tarafından kontrol edildiğinden hızlı bir şekilde ekip boyunca yayıldı.

Her şey genel yazılım geliştirme sürecine bağlıdır. Yapılandırma yönetimi ve yeni bir sürümün nasıl geleceği, genel süreç hakkında bilgi sahibi olmadan tanımlanamaz.

"Her zaman çalışan ilk taahhüt alanı" nı seçecek olan "çevik" hizip var. Bu alana karşı otomatik inşa ve test tesisleri işletecekler ve "her zaman" bir çalışma sistemine sahip olmaya çalışacaklardı.

Belki 1,2 ara basamak organizasyonuyla (usta) -> (serbest bırakma) faydalı görürlerdi.

Daha sonra, "iş birimi" sürümünün "yalnızca (birim) test edildiğinde serbest bırak" gibi gereksinimlerle planlanmış bir etkinlik olduğu, kilometre taşlarına doğru planlama ve planlı entegrasyon adımlarının yönlendirdiği bir sürece sahip daha "klasik" hizip var. ve bir sonraki planlanan dönüm noktasına sığması gerekiyordu ". Burada planlama, "iş birimlerinin" versiyonunu içerir ve tipik olarak, bir sonraki planlanan ürün sürümünün özellikler ve düzeltmeler açısından nasıl görünmesi gerektiğini tanımlamak için uzunluklara gider. Planlama uğruna, bir geliştiricinin bıraktığı şeyin "uygun" olduğunu ve bir birim iş yapma konusunda bilinçli bir hareket olduğunu bilmek isterler.

Bu klasik yaklaşım, tam bir ürün yapısının olmadığı daha uzun zamanların olduğu anlamına gelmez.

Yani "klasik" iş akışı şu şekildedir: (dev) -> (birim) -> (entegrasyon) -> (test / qa) -> (üretim).

Entegratörün rolü, piyasaya sürülen birimleri "kabul etme / satın alma" veya bir sonraki gelecek sürümün ihtiyaçlarına uymamaları durumunda reddetmektir.

Bir yan notta, bu 2 temel yaklaşımı fırsatçı yöntemlerle karıştırmak da mümkündür.

Deneyimime göre (çoğunlukla "klasik" yaklaşımı kullanma alanındaydı), "klasik" yaklaşım bir takımda yaklaşık 4-50 kişilik projelerde iyi çalıştı.