Git'te test dallarını kullanma

Yeni özellikleri ve hata düzeltmelerini test etmekten sorumlu birimiz var (ona Ted diyelim).

Git ve GitHub kullanıyoruz . masterher zaman konuşlandırılabilir olmalıdır / developmentyeni özellikler veya hata düzeltmeleri taahhüt ettiğimiz / birleştirdiğimiz yerdir, ancak yalnızca Ted tarafından test edildikten sonra.

Proje PHP'dir.

Test sürecinin şöyle devam etmesini istiyorum:

1. O çeker böylece bir geliştirici, (hadi Ted olarak # 123 sorun izleyicide belgelenmiş özellik / gýcýk demek) yeni bir özellik üzerinde çalışmaya istiyor origin/developmentiçindevelopment onun yerel depo ve (diyelim ki yeni bir şube oluşturur issue-123itibaren) orada.
2. İşinden memnun kaldıktan sonra, yeni şubesini origin .
3. Ted test.ourproject.com/choose-branch, şubelere bağlanır ve dalların bir listesini görür originve açmayı seçer issue-123(web sayfası üzerinden yapılabilir). Daha sonra devam ediyor test.ourproject.com, web uygulamasından cehennemi test ediyor (gerçekten acımasız) ve geliştiriciyle bir süre sonra tekrar tekrar, özellikten memnun.
4. Ted o birleştirebilirsiniz geliştirici söyler issue-123üzerine developmentüzerine origin.
5. Durulayın ve tekrarlayın.

Üçüncü adımda, işi yapan bir şeyi hackleyebilirim (belirli bir sayfadan dalları göstererek ve değiştirerek), ancak tarif ettiğim şeyin çok yaygın bir model olduğunu hissediyorum.

Yani sorum şu: Bu dallanma için iyi / sürdürülebilir / sürdürülebilir bir iş akışı mı? Bu iş akışını izleyen diğer projelerin bazı örneklerini göstererek cevabınızı yedekleyebilir misiniz?

Şube iş akışı gitflow'a çok benziyor http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow ve çevresinde destek araçları var. Şiddetle tavsiye edilir.

Sadece bir test cihazı varsa, test iş akışınız iyi gelir, ancak birden fazla kişi varsa, geliştirme başlangıç ​​ve bitiş arasında hareket edebilir ve elbette test herhangi bir birleştirme işleminden sonra tam olarak gerçekleştirilmelidir. Otomatik test gerçekten yardımcı olabilir veya yavaş (kapsamlı) bir test cihazı asla bitmeyebilir!

Başka bir sorun, birçok özellik ve dalda, özellikleri bir sürüme karıştırmak ve eşleştirmek (veya kabul ve birleştirme işleminden sonra tahliye etmeyi seçmek) veya belki de özellikler birbirine bağımlıysa temperlenmeye başlamasıdır. Sorun, YAYINLANMIŞ bir dalda geçmişi yeniden yazmak (veya bir kesinleştirme veya birleştirme silmek) için cazip olmaya başlarsanız, yani çok bölümlü bir repoya itilmiş olan bir dalda. Bu, kamu tarihinin yeniden yazılmasıdır. İyilik ya da kötülük için yapılabilir ve iyilik için yapılsa bile uyanık olmayan sorunlara neden olabilir ve en iyi uygulama bundan kaçınmaktır, böylece soru asla ortaya çıkmaz. Bununla birlikte, bazı entegrasyon dalı iş akışları bunu çok cazip hale getirir, bu nedenle bu dallar üzerinde güçlü bir korumanız varsa (örneğin, kullanıcı dalı kısıtlamaları başına gitolit) ve insanlar böyle bir faaliyet bekler, bu nedenle böyle bir daldaki kodlarını her zaman yeniden adlandırın, dikkatli olun!

Ayrıca , tüm bu konuları tartışan ve birçok iyi referansı olan http://sethrobertson.github.com/GitBestPractices/ adresini okumanızı tavsiye ederim .

Anahtarlama sayfasının kendisinin ortak bir kalıp olduğundan emin değilim. Çoğu proje muhtemelen test cihazının git komutuyla kontrol etmesini sağlar.

Genel yaklaşım kesinlikle makul görünüyor.

Google, Gerrit'i benzer stili desteklemesi için bile yazdı ; daha çok kodu gözden geçirmekle ilgilidir, ancak entegrasyonu onaylamak normalde hem inceleme hem de test gerektirir. Genellikle ilk olarak tüm gönderimleri oluşturan sürekli entegrasyon sunucusuyla da bağlantılıdır ( Jenkins kullanıp kullanmadıklarından emin değilim) Google'da , ancak bir yerde uygun konektörler gördüğümü düşünüyorum).

Git'in kendisi tema üzerinde küçük bir varyasyon kullanır. Bakıcısı, beklemedeki tüm gönderimleri adlı bir şubeyle birleştiren bir komut dosyasına sahiptir pu(muhtemelen "önerilen güncellemeler için"; beklemedeki gönderimler genellikle yeniden temel alındığı için şube silinir ve yeniden oluşturulur). Bu, çeşitli insanlar tarafından test edilir. Eğer iyiyse, tam olarak kabul edilen gönderimler birleştirilir next(bu sizinkiyle aynıdır development). Değilse, bir kişi daha hangisinin kırıldığını görmek için bireysel gönderimleri test eder. Bu, çoğu zaman şubeleri değiştirmek zorunda olmadıkları için test cihazı için biraz daha kolay hale getirir; test entegrasyonunun çalışıp çalışmadığını rapor ederler.

Testiniz manuel yerine otomatik olarak yapılırsa, Travis'in (GitHub için bir CI sistemi) hemen hemen istediğinizi yapacağını düşünüyorum - otomatik olarak tüm çekme isteklerinde testleri çalıştırır. ( Ekran görüntüleri de dahil olmak üzere bu işlem hakkında daha fazla bilgi. )

Testlerin dalda değil, dalda master ile birleştirildikten sonra yapıldığını unutmayın. (ör. şubeyi master ile birleştirdikten sonra alacağınız şey - testlerin birleştirmeden sonra da başarılı bir şekilde çalışacağından emin olabilirsiniz.)

Şubeye taahhütler eklenirse, testler yeniden yapılır. (Bazı nedenlerden ötürü ustaya ekleme taahhüdü testleri tekrar yapmıyor gibi görünüyor.)