“Geliş” şubesinin eğilimi uzuyor

Son zamanlarda GitHub'daki bazı popüler projelere baktığımda, developşubesi olmayan bir şey fark ettim . Ve aslında, GitHub Akış kılavuzu da ondan bahsetmiyor. Anladığım kadarıyla, masterher zaman tamamen kararlı olmalı ve üretimi yansıtmalıdır. Geliştiriciler özellik dalları üzerinde çalışıyorsa ve bunları masteryaptıklarında birleştiriyorsa , bu özelliklerin / düzeltmelerin birleştirildiği masterve masterdalın aslında üretimden daha yeni olduğu bir süre olduğu anlamına gelir .

Ekibin özellik yaratması / dallarını düzeltmesi develop, tekrar birleşmesi ve bir sonraki sürümün yayınlanmaya tamamen hazır developolmasıyla birleştirilmesi masterve bir etiket yaratılması daha anlamlı olmaz mıydı ? İnsanların doğrudan bir araya gelip gelmediğini masterve masterbranş kod tabanı önemli ölçüde değiştiği için üretimde düzeltilmesi zor olan bir hata bildirildiğini hayal edin . O zaman devs, kullanıcının sorunu çözdüğünü görmesi için bir sonraki sürüme kadar beklemesini söylemelidir.

EDIT: Bu soru "şube ya da değil daldan" farklıdır. Özellikle gelişmekte olan şubeyi kullanmaktan uzaklaşan insanlara ve onu çevreleyen sebeplere hitap ediyor, çünkü uzun zamandır en iyi uygulama olarak görüldü.

Günde birkaç kez entegrasyonun olduğu CI zihniyetinden geliyor .

Her ikisinin de artıları ve eksileri var.

Ekibimizde gelişme branşını da terk ettik, çünkü ek bir fayda sağlamadığını, birkaç dezavantajı olduğunu hissettik. CI yazılımımızı (Teamcity) dezavantajları telafi edecek şekilde yapılandırdık:

1. Belirli bir taahhüdün dağıtımını etkinleştirin. Başka bir deyişle: Bir şube dağıtmıyoruz. Bir taahhüt veriyoruz.
2. Düzeltme / önek ile başlayan ana veya dalları dağıtabiliriz.

Bunun işe yaramasının nedeni, tüm çekme isteklerinin potansiyel olarak serbest bırakılabilir kod içermesidir, ancak bu, tüm komisyonları ana sistemde dağıttığımız anlamına gelmez.

Gelişim branşını terk etmemizin ana nedeni, gerçekte ne içerdiğini görmek için fazla büyük ve zaman alıcı olma eğiliminde olmasıdır. Eğer biraz erken bir şey konuşlandırdıysak, sadece bir düzeltme dalından ayrılır ve doğrudan konuşlandırılır.

Bir geliştirme kolu, serbest bırakma işleminiz karmaşıksa ve ciddi serbest bırakma adaylarına ihtiyacınız varsa daha önemli.

Örneğin, arabalara üretici yazılımı yazdığınızı hayal edin. Bu ... düzeltmek için önemsizdir ve herhangi bir sürümün gerçek donanım üzerinde yürütülen kapsamlı bir dizi CI / entegrasyon testi içermesi muhtemeldir.

Bu durumda, bir “serbest bırakma adayını” usta olmayan bir dalda (“geliştir” gibi) izole etmek daha mantıklı olabilir. Bu, testlerinizi yapan ekibinizin özellikleri birleştirmek için bir şubeye sahip olmasını sağlar.

Webapps veya başka bir kolay güncellenen yazılım bu kısıtlamaya sahip değildir.

Ancak şunu unutmayın:

• Github'daki pek çok (en?) Proje bu tür bir kısıtlamaya sahip değildir.
• Ana "usta" aynı amaca hizmet eder
• "PR vs usta yapmak" iş akışı, "bu depoda hemen bilmediğiniz bir şubeye karşı PR yapmak" tan çok daha evrenseldir.

Projelerde gördüğüm iki felsefe var ve bence seçim sadece bir zevk meselesi:

1. 'Master'ı' üretim sürümü olarak belirtin ve 'geliştir' dalında geliştirin.

2. 'Usta' geliştirin ve istikrarlı üretim sürümleri için farklı adlandırılmış bir şubeye sahip olun. Bu, projenizin bir defada birden fazla salınım koluna sahip olması durumunda daha da mantıklı (örneğin, şu anki tercih edilen Yayım-1.8'dir, ancak aynı zamanda Salım-1.7'yi sürdürüyorsunuz).

Her ikisi de ortak yaklaşımlardır ve artıları ve eksileri vardır.

Üretime ilişkin sürümler etiketlenebilir, böylece serbest bırakılan durum, bu amaçla bir şubenin tamamını ayırmadan her zaman çoğaltılabilir.

Master'ın piyasaya çıkmayacağı bir anda üretimde kritik bir hata bulunursa, etiketi kontrol edip buradan "release-release-1.2.0" için yeni bir düzeltme başlatmak yeterlidir. Ancak bu oldukça nadir olmalı.

Web uygulamalarımızda çoğu zaman, son sürümden bu yana master değişti, ancak çok da önemli değil, bu nedenle düzeltmeyi yapan master'dan yeni bir sürüm yapabiliriz. Yine de çok sık yayınlanmasına yardımcı olur.

Geliştiriciler özellik dalları üzerinde çalışıyorsa ve daha sonra bunları master'la birleştiriyorlarsa, bu özelliklerin / düzeltmelerin birleştirildiği masterve masterdalın aslında üretimden daha yeni olduğu bir süre demektir.

...

İnsanların doğruca ana ile birleştirilip birleştirilmediğini ve ana dal kod kod temeli önemli ölçüde değiştiği için üretimde düzeltilmesi zor olan bir hata bildirildiğini hayal edin.

Bu Github Flow değil.

Bu, Github Flow dağıtım / birleştirme işlemidir, bağlantınıza göre:

Dağıtmak

Çekme isteğiniz incelendikten ve şube testlerinizi geçtiğinde, değişikliklerinizi üretimde doğrulamak için dağıtabilirsiniz. Şubeniz sorun çıkarırsa, mevcut master'ı üretime sokarak geri alabilirsiniz.

birleşmek

Değişiklikleriniz üretimde doğrulandıktan sonra, kodunuzu ana şubede birleştirme zamanı gelmiştir.

(Vurgu madeni)

Başka bir deyişle, masterasla üretimin önünde olmayacak. Benzer şekilde, masterher şey kararlı, serbest bırakılabilir bir durumda olacaktır (keşfedilmemiş böceklerin yanı sıra), çünkü her şey birleştirilmeden önce incelenip test edilmekte ve üretime sunulmaktadır master.

Gördüğüm mesele, Git / Hub akışının konuşlandırma / birleştirme işleminin bir özelliğin bir seferde geliştirildiğini / test edildiğini / birleştirildiğini / konuşlandırıldığını varsayıyor olması. Bir özelliği bir seferde birleştirdiysek, gerileme sorunları için daha büyük bir şans var - sadece özellikler ana ve muhtemelen üretimde birleştirildikten sonra bulunur.

Birden çok özelliği test etmenin, birden çok özelliği birleştirmenin ve aynı şeyi dağıtmanın bir yolu olması gerekir. Qa / uat'a yerleştirilen bir 'paket dalı' (ustadan sınamaya hazır özellik dalları ile birleştirilen bir şube) kullanıyorum. Uat sırasındaki düzeltmeler yalnızca özellik dalında gerçekleşir ve bunlar paket dalına yeniden birleştirilir. Paket dalının bir alt bölümünün onaylanmasından sonra, yalnızca paket içindeki onaylanan özellikler master için talep edilir - döngü süreklidir.

Bunu Gitflow ile kullanıyorum, ancak GitHub akışı için kullanmaya karar verdim. QA / UAT bir zaman meselesinde birçok özellik önemli görünüyor. GitHub akışıyla ilgili bir diğer sorun, tüm sr geliştiricilerini varsaydığı ve bu her zaman böyle olmadığıdır.

GitHub akışını sadeleştirilmiş olması nedeniyle kullanmayı tercih ederim. Paket benzeri bir özellik ile daha iyi hazır olacağını düşünüyorum. Paketin piyasaya sürülmeye benzer olması mümkün; Ancak, ben de hala bu konuda düşünmek.

Diğer bir sorun ise, çekme isteği işleminin sonunda master ile birleşme öncesinde gerçekleşmesidir; ancak, bazen işletme qa testinden önce incelemeyi kodlamak istersiniz - bu nedenle birleştirme işleminden hemen önce