Bir yapı neredeyse her zaman kırıldığında nasıl verimli olunur

Aynı kaynak kodunu paylaşan ve sürekli entegrasyon devam ederken orta ölçekli bir takımda çalışıyorum, ancak hepimiz aynı dalda çalışmak zorunda kaldığımız için, yapı neredeyse her zaman bozuluyor.

Ayrıca, son zamanlarda ortaya çıkan ve kırılan binaları hafifletmek için uygulamaya konan bir kurala sahip olduğumuzdan, kimsenin inşa ederken check-in yapmasına izin verilmediğini belirten kırmızıdır.

Bir gün boyunca, herkesin check-in yapabilmemiz için 10-15 dakikalık bir avuç penceresi olduğunu söyledi.

Ekip büyürken, check-in olanaklarının pencereleri daha da daralmaktadır. Bu, geliştiricileri yerel olarak değişikliklerini biriktirmeye zorlar ve bu da değişikliklerin hiçbir şeyi kırmamasını sağlamak için daha da zor olan daha büyük değişiklik kümeleriyle sonuçlanır. Kısır döngüyü görebilirsiniz.

Böyle bir ortamda etkili bir şekilde çalışmama izin vermeme ne önerebilirsin. Ayrıca, bir yönetici değil geliştirici olduğumu ve süreci ya da diğer insanların davranışlarını çok fazla değiştiremeyeceğimi unutmayın.

Başlangıç ​​olarak, bu yorum:

... bir şubeye sahip olmak ekstra bir karmaşıklığa ve dolayısıyla ek işlere işaret eder ...

tamamen yanlış. Çoğunlukla dallanmaya alışkın olmayan insanlardan duyuyorum, ama yine de yanlış.

Yerelde birçok biriken değişiklik yapan geliştiriciniz varsa, yerel değişiklikleri ana havuzun fiili bir şubesini oluşturur.

Sonunda zorladıklarında, bu fiili bir birleşmedir .

Şubelerinizin ve birleştirmelerinizin örtük olması, endişelendiğiniz ekstra karmaşıklığı ortadan kaldırmaz, sadece gizler. Gerçek şu ki, bu süreci açık hale getirmek size (çoğul = tüm ekip) yönetmeyi öğrenmede yardımcı olabilir.

Şimdi diyorsun

inşa edilirken kimse giriş yapamaz

ancak bu durumda yapı asla düzeltilemez, bu yüzden tam olarak doğru olamaz.

Genel olarak, yerel olarak inşa etmek makul ise (yani, inşa çok büyük veya yavaş değilse ), geliştiriciler bunu yine de zorlamadan önce yapmalıdır.

Sanırım bu durum böyle değil, çünkü o zaman kırılmış binaları ilk etapta zorlamazlardı, ama bu noktayı netleştirmek için harika olurdu.

Genel olarak cevap

Bir yapı neredeyse her zaman kırıldığında nasıl verimli olunur

is: yapıyı kesmeyi bırak .

geliştiriciler ... yerel olarak değişikliklerini biriktirir ... Kısır döngüyü görebilirsiniz.

Gerçekten de kısır. Değişiklikleri yerel olarak biriktirmek, dev işleminde bir şeyin ciddi şekilde çürüdüğünü gösteren büyük bir kırmızı bayraktır. Sürüm kontrol sistemine sahip olmanın tüm amacını bozuyor .

Süreci veya diğer insanların davranışlarını değiştirmekten uzak durmak istediğiniz sürece, en doğal çözüm, kendi şubenizi oluşturmak ve değişikliklerinizi "biriktirmek" için kullanmaktır (aldığınızda ekip şubesiyle daha da entegre olmak) şans).

Aslında, sizin gibi daha fazla kişi varsa, yetersiz yönetim fikirlerine müdahale etmeden güncellemelerinizi özgürce değiş tokuş etmek için ortak bir geliştirme dalı kurabilirsiniz. Dallanma , ekip çalışmasını basitleştirmenin birçok farklı yolunu sağlar.

• ^{Yan not, müdür her yaptığınızda veya sizi taahhütten kaçınmaya zorlayan, kodları yerel olarak tutmaya zorlayan bir şey söylediğinde, kelimelerini cesur ve sade bir şekilde "Ben beceriksizim" e çevirir .}

lütfen bir yönetici değil geliştirici olduğumu ve süreci ya da diğer insanların davranışlarını değiştiremeyeceğimi unutmayın.

Hassasiyet uğruna, aslında olabilir , bu etki ve iletişim becerilerinin konulardır ve kimse gerçekten onların böyle bir şey için web'de arama (sevme değişiklik şeyler gücün konumunda olması gerekmez "yukarı yönetmek" eğer daha fazla ayrıntıyla ilgileniyorum).

Ancak en doğrusu hantal ve çaba harcayan ve bir sade kalmak için tercih ediyorsa ben mükemmel anlayabileceği siyasette çok az katılımı ile, kodlama odaklanmış - böylece yoksa istiyorum (eğer teoride olsa can ), anlaşılabilir bir durumdur. :)

Çevreyi değiştirmek için güçsüz hissettiğiniz fikrine karşı hassasım, ancak bu durumun bir programcı olarak profesyonelliğiniz için ciddi bir zorluk olduğunu düşünüyorum.

Bir cerrah kirli neşterleri temiz olanlarla birlikte saklarsa ne olur? Bir tesisatçı kurduğu boruları test etmeseydi ne olurdu? Bir kemancı her zaman orkestra ile uyum sağlamış olsaydı ne olurdu?

Programcılar neden takım çalışmasından ve ortak nezaketten muaf tutulmalıdır? Bu ekibin bir üyesi olarak, sonuç için sorumluluğu paylaşırsınız. Kendi çabalarını sabote ettiği için takımı görmezden gelmek sorumluluğu yoktur.

"İnşa ederken kimsenin check-in yapmasına izin verilmeyeceği" kuralının nereden geldiğini merak ediyorum. Bu, herkesi yapıyı düzeltmeye odaklarsa iyi bir kuraldır. Örnek olarak yol göstermeye çalışıyorum ve ne zaman kırılsa yapıyı düzeltmeye yardım ediyorum. Kabul edelim, başka bir şey yapamazsınız. Bu sizi kızdırırsa, bu endişeleri dile getirmenizi öneririm. Aktif olarak bir durumu iyileştirmeye çalışan birinin sesi köşedeki homurdanan adamdan daha fazla etkiye sahiptir.

Bence "sadece bir geliştirici" olduğunuzu düşündüğünüz ve bu nedenle yaşayacağınız şeyleri değiştiremeyeceğinize inanıyorum.

Yapmanız gereken şey, birisinin yapıyı kırdığı her seferde depodan aldığınız her işlemi geri almanız ve ardından o adama henüz yapıyı kırdığını ve bunun durması gerektiğini söylemesidir. Ayrıca, bu durumu yöneticiye açıklamanız ve ekibinizin verimliliğinin bu sorundan dolayı acı çektiğini söylemeniz gerekir.

Süreci daha iyi değiştirmek için elinizden gelen her şeyi yapmanız ve izin istemek yerine daha sonra üzgün olduğunuzu söylemeniz gerekir.

Siz ve ekibinizin, sürecin değişmesi gereken bir durumda olduğunuzu ve o kırık modelle verimli çalışamayacağınızı düşünüyorum. Ayrıca, farkettiğinizde bu sorun hakkında bir şeyler yapmak sizin sorumluluğunuzdadır. Sorun hakkında başka kimse bir şey yapmayacaksa, yapması gereken sensin!

Sizin durumunuzla ilişki kurabilirim, işteki en son projemle benzer bir durumla karşılaştım. Bir nevi o kadar en son yapı kırdı geliştirici Babysit / dadı / onu izlemek zorunda "sıcak patates" Sistemin uygulanması sona erdi sabit VE geçti tüm doğrulama testleri.

Bu başarılı oldu çünkü yapı ve doğrulama testleri düzenli olarak 4 saat sürdü, bu nedenle yapıyı kesmek, gerçek iş yaparken yarım gün kaybettiğiniz anlamına geliyordu. Bunu söylemeye gerek yok, geliştiricilerin gövdeleri birleştirmeden önce dalları daha verimli kullanmalarıyla sonuçlandı. Çoğu geliştirici için, önceki zihniyet "Kodum bozulursa CI inşa sisteminin bana haber vermesine izin vereceğim."

CI sisteminde yapılan basit bir değişiklik bunu yapar: yapıyı bozan herhangi bir değişiklik otomatik olarak geri alınır. Daha da iyisi, CI deposunun, yapı yeşil olduğunda değişikliklerin yalnızca yetkili depoya iletildiği aşamalı bir alan haline gelmesine izin verin. Gerrit gibi araçlar burada yardımcı olabilir.

Burada iki şey daha yardımcı olabilir:

• ekibiniz yerel olarak inşa edilmiş bir CI'yi test edebilir mi? Yapıyı bozmadığınızı kontrol ederseniz - ya da en azından yönetim ve ekip işini yapmanıza ve tetiklemenize gerek kalmadan yapıyı ortak yollarla kırmayın.
• CI'yi nasıl tasarladığınıza bağlı olarak kırık yapıları tanımlamanın birçok yolu vardır. Bu, kırılmayı tanımlamayı da içerir - ağır gelişme altında başarısız testlerin bir mola olduğunu düşünmüyoruz, daha doğrusu çalışılması gereken bir hedef.

Ama gerçekten şubelere bakmalısın.