Geliştiricileri, özellik bayrağı geçişlerini kullanmaya başlamaya nasıl ikna edebilirim?

Bu özellik bayrağı geçişlerinin iyi bir fikir olduğunu ve geliştiricilerin yazdığı koda uygulanması gerektiğini varsayarsak. Örneğin Etsy , kültürlerinin önemli bir parçası olarak onlara yemin ediyor .

Geliştiricileri, özellik bayrağı geçişlerini kullanmaya başlamaya ikna etmenin (ve zorlamanın) iyi bir yolu nedir?

Özellik bayrağı geçişleri hakkında daha fazla bilgi S: Özellik bayrağı geçişlerini kullanma , S: Özellik bayrağı geçişleri nedir ve Pete Hodgson'un Martin Fowler'in blogundaki konuyla ilgili makalesinde çok kapsamlı olarak açıklanmaktadır .

Özellik geçişleri, gelişimi hızlı bir şekilde serbest bıraktıklarından, yüksek hızlı geliştirmede yaygın bir uygulamadır . Geliştirici ekipleri, üretim için yeni bir özelliği devre dışı bırakılmış bir durumda "yumuşak bir şekilde serbest bırakabilir". Bu, özelliğin her zaman serbest bırakılmasını sağlar. Özellik başka bir çalışmaya veya hazırlığa bağlıysa, büyük bir sürümün üretime geçmesini beklemek zorunda değildir.

Geliştiricileri, onları kullanmaya ikna etmekle birlikte, bu, sunduğu özgürlük için dava açma alıştırmasıdır. Deneyimlerim, geliştiricilere zor bir satış olmaması. Yeni şeyler denemek konusunda isteksiz davranan yönetimdir. Bunu dene:

• Bir özellik geçiş çerçevesi bulun. Yönetim / işletme ortak bir sistem tarafından desteklenen bir şeyi denemeye daha uygun olabilir
• Küçük başla. Geçiş sistemini, faydasını gösterecek bir özellik için deneme temelinde tanıtın.
• Geçişin A / B testi yapma yeteneğini gösterin. Web grubunuzun bir alt kümesi için geçişi etkinleştirin, ardından davranışla ilgili metrikleri toplayın. Sayfa düzenindeki küçük farklılıkların perakende uygulamaların gelirleri üzerinde büyük etkileri olduğu gösterilmiştir (örn. Ebay, Amazon)

İdeal bir dünyada yeni bir yapı ve sürpriz oluşturduğunuzu düşünüyorum! Hiçbirşey değişmez. Bunun nedeni, tüm yeni özelliklerinizin, anahtar kapalıyken çıkan anahtarların arkasında olmasıdır.

Dağıtım sonrası, verilen hizmetinizin hala çalıştığını doğrularsınız, telefonlar artık çalmaz (telefonları çalmak sizin amacınız olmadığı sürece, vb.). Bilinen istikrarlı bir işleme geri döndüğünüzde, etkinleştirmeye ve doğrulamaya başlarsınız. yeni dağıtılan özellikleriniz.

Şimdi cevabınız için: Çağrıda bulunmanın pratikte beyinsiz olduğu ve kullanıcılarımızın bizi sevdiği bir ekip üzerinde nasıl çalışmak istersiniz, çünkü sitelerimiz ve hizmetlerimiz kaya gibi sağlamdır?

Üzerinde çalışmak istediğim ekip bu.

İsterseniz burada okumayı durdurabilirsiniz.

Her şeyi bir özellik anahtarının arkasına koymak, her yerde spagetti koduna yol açabileceği gibi görünüyor. IoC kullanıyorsanız ve vNow / vNext / vPrevious arasında seçim yapabiliyorsanız, yapılandırmanızı sürdürmeye gelir. Evet daha fazla check-in, evet daha fazla sınıf (componentV1, componentV2, componentV3, vb.) Ama aslında daha kararlı bir sisteminiz var mı? Nasıl? vSonraki sakat mı? Kontrol kulenizle vNow'a geri dönün. Bir hafta oldu ve vNow ince bir hata var mı? Aynı şey - vPrevious'e kolayca gidin.

Sorun yok, endişe yok, uyku kaybı yok, stres yok.

Bu bir hayal değil. Orada çalışırdım. Bunu şimdiki ekibime satabilseydim.

Başarılı bir yüksek hızlı geliştirme ortamı tipik olarak regresyonlara neden olan hatalı değişikliklerin tespiti ve reddedilmesi ile kalite doğrulamaları içeren oldukça katı bir otomatik sisteme dayanır.

Özellik geçişleri, entegrasyon dalında gerilemelere neden olduğu için reddedilmeden, devam eden çalışmalarda, test edilmemiş değişikliklerde bile işlem yapma olanağı sunar. Hangi özelliği tanıtmak için çok iyi bir teşvik oluşturur özelliği hayatının çok erken arasında geçiş yapar.

Gerçek CI'den sapmanın ve özellik dalları üzerinde hareket eden özellik geliştirmenin dezavantajlarından biri, böyle bir teşvikin olmamasıdır. Özellik geçişini daha sonra eklemek, özellik dalını tümleştirme dalına birleştirirken, geç tümleştirme gibi genellikle daha zordur.

Geliştiriciler (ve genellikle geliştirme yöneticileri) genellikle çerçeveyle ilişkili iki sonuç arar: yönetim kolaylığı ve uygulama hızı. Kodu daha hızlı ve daha kolay göndermek istiyorsunuz.

Yaklaşımın işe yaradığına dair kanıt sağlayın; eski yolla özellik bayraklarını kullanarak küçük bir POC oluşturmayı deneyin. Vaka çalışmaları taktik insanlar (geliştiriciler \ mühendisler) için stratejik insanlardan (orta yönetim \ ürün tasarımcıları) daha az önemlidir.

Özellik geçişlerinin mantığı, geliştiricilerin karar vereceği bir şey değildir. Bu, ürün sahiplerinin ilgilenmesi gereken bir şeydir. Geliştiriciler bu değişikliği en sürdürülebilir ve güvenli bir şekilde sağlıyor. Bu soruyu eleştiriyorum.