Geliştirmek için birleştirilmiş bir özellik yönetim tarafından ertelenirse ne olur?

53

Son zamanlarda webapp'ımızın (otomatik kayıt olma) bir özelliğinin yönetim tarafından ertelendiği için bir sorun yaşadık, çünkü başlangıçta "soğuk" olduğunu hissettiler, ancak üzerinde çalışmak için çalıştığımız diğer tüm özellikleri istediler.

Sorun, bu işlevselliğin bir sonraki sürümde canlı yayınını beklediğimiz tüm diğer özelliklerle birlikte tamamlandığında gelişmesiyle bir araya gelmesiydi, böylece genellikle yaptığımız gibi dev -> test -> ustasını birleştiremezdik.

Bu sorundan nasıl kaçınabilirdik?

project-management git gitflow

— Steve
kaynak

Bunu nasıl çözmek istediğinize bağlı olarak bakış açınıza bağlı olarak, teknik bir çözüm aramıyorsanız, bu soru işyeri için daha uygundur.

— Malavos,

74

Bir yaklaşım, onu işaretleme özelliğidir. Kod tabanında yaşayabilir ancak yapılandırma ile devre dışı bırakılabilir.

Başka bir seçenek, birleştirme özelliğini geri döndüren bir işlem yapmaktır; Geri döndürülen ve daha sonra birleşme beklemede bırakılan yeni bir şube yapılabilir. Github çekme isteklerini kullanıyorsanız, bunu birleştirilmiş bir çekme isteğindeki "geri alma birleştirme" düğmesiyle kolayca yapabilirsiniz.

— Daenyth
kaynak

9

Yapılandırma işaretlemesi, bu kod için test etme çabasının iki katına çıktığı anlamına gelmiyor mu? Her iki yolu da test etmelisin .

16

Bu durumda, üretimde o bayrağını açmayacağınız için, şu anda piyasaya sürülmek üzere kapalı vakayı test edebilir, daha sonra prodüksiyona hazır olduğunda vakayı test edebilirsiniz. Bu, bir geri döndürme sınaması ve yeniden başlatmayla yaklaşık olarak aynı iş olmalıdır.

— Alan Shutko

4

Ortak terim, Özellik Geçiş özelliğidir . Küçük bir "özellik giriş noktası" varsa, bu muhtemelen yönetim kararından sonra yapılabilir. Olmazsa, bu yöntemde olduğu gibi herhangi bir yöntemde de sorun yaşanacaktır.

— Doc Brown

3

Feature TogglingDoc Brown'un dediği gibi, 6 ay boyunca geliştirilmekte olan ve gizlenen özelliklere sahibiz . Bu aynı zamanda üretim dışı ortamlarda da özelliğini (veya yokluğunu) test etmemize izin verir. Bazen bu özellikler mevcut özelliklere eklenir, bu durumda hem eski hem de yeni özellik kümesi için birim testleri yapmalıyız. Her birim testi sadece bayrağı geçerli testi yapmak için neye ihtiyacı varsa onu ayarlayacaktır.

— ps2goat

25

Bu sorundan nasıl kaçınabilirdik?

Bir süreç açısından bakalım:

Bu çalışmaya başlamak için karar veren kimdi?
Bu özelliği serbest bırakma kararı neden değişti?
- Beklenen cevaplar?
- İletişimsizlik?
- Yetersiz iş desteği?
- Müşteri katılımı yok mu?

Büyük olasılıkla, yol boyunca iletişimde düşüşler oldu. Bunun olması önemlidir, çünkü işe yaramadığı zaman, gelişim süreciniz yanlış ve yanlış iş gereksinimlerinin anlaşılmasına dayanacaktır.

— enderland
kaynak

9

10. Yönetim, özelliklerin yayınlanmasından şüphe etmeye başladığı anda, geliştiricilere bilgi vermiş olmalı, böylece özelliği geliştirmek üzere birleştirme kararı alırken olası kaldırma işlemleri göz önünde bulundurulabilecekti.

— Bart van Ingen Schenau

14

Bu çok yapıcı bir cevap değil - bazen her türlü sebepten dolayı işler ters gidiyor. Tabii, bir araya gelmeden daha erken bir zamanda birleştirilmemesi gerektiğini bulmak önemlidir, ancak bu, en sonunda son dakikada bir özelliğin çekileceği anlamına gelmez. Belki sözleşme değişir, belki müşteriniz ödeme yapmaz, belki yasal meseleler ortaya çıkar .. suçu işaret etmek yerine hala sorunu yönetmek zorundasınız

— gbjbaanb

11

Kuruluşunuzda, hata kabul etmeyi reddetmek için yeterince güçlü ve ayrıca hatalardan kaçınmamak için yeterince çocukça insanlar varsa, o zaman kendi bilgileriniz için hala ölüm sonrası sorunları yapmalısınız. Sadece onlara söylemek istemiyorsunuz (ya da açıkça yazıyorsunuz). Bununla birlikte, enderland "suçlama" kelimesini kullanmaz ve eğer kuruluş bu tavsiyeyi "kimin suçlu olduğunu bulmak" olarak yorumlarsa, o zaman bu organizasyon üzerinde çalışmak için bir problemdir. Tüm bunlar, “sorunun neden ortaya çıktığını anlamak” olduğunu ve gelecekte de bundan kaçınmak için esastır.

— Steve Jessop

2

Tamamen aynı fikirdeyim, bu bir geliştirici değil yönetimsel bir bozulma.

— durron597

3

@enderland, benim açımdan bazı sorunlardan kaçınamayacağınız, bu yüzden durumu nasıl onaracağınızı düşünmeniz gerekiyor. Umarım çok sık sık elde edemezsiniz, ancak er ya da geç gerçekleşmesi kaçınılmaz, buna göre planlayın.

— gbjbaanb 02:15

19

Bir an için yönetiminizle ilgili sorunu unutun ve kod tabanınıza derinlemesine entegre edilmiş olan en son üretim sürümünüzde "otomatik kayıt özelliğine" sahip olduğunuzu hayal edin. Şimdi "otomatik kayıt" için bir "kapatma" eklemek için yeni gereksinimi elde edersiniz. Git iş akışınızda bunu nasıl ele alırsınız?

Sanırım "yapılandırma ile otomatik kayıt işlemini devre dışı bırakma" yı ek bir özellik olarak (sadece bir Özellik Geçiş şeklidir ) ilan edersiniz, bu nedenle iş akışınıza sorunsuzca entegre edilmesi gerekir. İsterseniz bir özellik dalı kullanabilirsiniz (ya da böyle konular için özellik dalları kullanmıyorsanız), çabayı tahmin edebilirsiniz. Ve tarif ettiğiniz "birleştirme dev -> test -> master" akışını kesinlikle kullanabilirsiniz.

Ve bu aslında şu anki durumunuzda bununla başa çıkma şeklinizdir. Git iş akışı açısından, değişiklik isteğinin sürüm 1.0 için yönetimden gelip gelmediği veya değişiklik isteğinin sürüm 2.0 için yeni bir müşteri isteği olup olmadığı önemli olmamalıdır.

— Doktor Brown
kaynak

Fowler gerçekten iyi bir çıktıya sahip, ancak özellik tanıtımı için bu yöntemi destekleyemiyorum. Bu tür anahtarlar için koordineli çaba gereksiz bir yük gibi görünüyor. Ben yapabilirsiniz özelliğini ekleyerek birleştirme işlemi sonrasında özelliklerini kaldırmak için geçiş yapar, ancak zorunluluğunun bir parçası olarak bir anahtar bina beni rahatsız edecek destekler.

— Gusdor

@Gusdor: düzenlememe bakın.

— Doktor Brown,

1

Gitflow ve GitHub akışıyla ilgili tam sorunum bu ve web uygulamalarında bu sık sık oluyor - ya da norm gibi. Bu sorunu geriye dönük olarak (yukarıda belirtilen) ya da proaktif olarak (aşağıdaki örnekte) çözeceğiniz görülüyor.

Standart gitflow şubelerine ek olarak 'dal şubeleri' oluşturdum. Paket, uat / qa için hazır olan tüm özelliklerden oluşur. Uat / qa özelliklerinin bir listesi oluşturulur. Bunlar geçici paketle birleştirilir ve bu paket uat / qa'ya yerleştirilir. Herhangi bir hata onarımı, orijinal özellik dalında gerçekleşir ve bu da tekrar pakete yeniden eklenir ve dağıtılır. Bu, gelecek sürümü ayırmanın yanı sıra, bu özelliklerin, geliştirme dalına giden yollarını bulmadan önce birlikte test edilmesini sağlar. Onaylanan şubeler gitflow sürecini takip ederek gelişmeye yönelik bir talepte bulunur. Teste hazır özellikler geçici paket dalına eklenebilir veya kaldırılabilir ve yeniden konuşlandırılabilir.

Bu, master'ı her zaman üretime hazır durumunu yansıtan tutar (kanca ile otomatikleştirebilir)
Geliştirme her zaman en son teslim edilen (ve test edilen) sonraki sürüm adayını yansıtır

Eksileri, paket listesini yönetmeyi ve başka bir şube türü eklemeyi; Ancak, çok geç olduğunu düşündüğüm retro düzeltmenin yanı sıra, bu daha uygulanabilir bir çözüm gibi görünüyor.

Bir GUI eklentisi ile, paket dağıtımı başına özellik dallarını işaretlemek en uygun olabilir - otomasyon akılda tutularak.

— David Latty
kaynak