Çevik geliştirme dağıtım süreci. KG ve İşletme Sahipleri nerede test ediyor?

Son zamanlarda, çalıştığım yeri nasıl konuşlandırdığımızı yeniden tasarlamak amacıyla, SVN veya GIT kullanarak çeşitli web uygulaması dağıtım süreçlerinde çok şey okudum.

Agile'ın birçok lezzeti gibi, ustalaşmak veya gövdeye adanmış her şeyin üretime hazır olduğu varsayılır. GitHub ve Etsy, http://codeascraft.etsy.com/2010/05/20/quantum-of-deployment/ bu temelde çalıştıklarını söylüyorlar (Etsy'nin aslında bir hazırlama ortamı olmasına rağmen).

Bu işlem, tüm birim testlerinin ve CI testlerinin gerçekleştirildiğini varsayar. Testleri yerel olarak ve CI üzerinde yaparsınız ve daha sonra bagajda çalışmayı taahhüt edersiniz. Yani, bu noktada kodunuz teknik olarak sağlamdır.

Kodunuz teknik olarak doğru olabilir, ancak kullanıcı / işlev testi, özellikle ön uç testi söz konusu olduğunda daha fazla hata ortaya çıkarabilir.

Sorum şu. KG ve İşletme sahipleri uyguladığınız özellik değişikliklerini nerede test ediyor? Gövde üzerinde çalışmaya başlamadan önce yerel geliştirme makinenizde mi yoksa bir KG / evreleme makinesinde mi?

Bagajdan çıkan bir evreleme makineniz varsa ve gövdeye adanmış tüm kodların üretime hazır olduğunu varsayarsanız ... eh .. o zaman kod hangi noktada imzalanır ve hem teknik hem de iş dünyasından üretime geçmek için iyidir perspektif? Sadece bir evreleme makineniz, birçok geliştiriciniz ve kodun KG olması gereken yer varsa, birçok geliştirici değişikliği oturumu beklemeyi beklediğinden bagajdan nasıl dağıtabilirsiniz.

Başkalarının buna nasıl yaklaştığını duymak isterim?

Daha iyisi ya da daha kötüsü, genellikle testin şube tabanına karşı yapıldığı ve işin kapatılması, denetim noktasının konuşlandırma ana sistemiyle birleştirilmesinin ne olduğu olduğunu görüyorum.

Bunu "ana" üzerinde ayrı bir "konuşlandırılmış" dal ile geliştirme veya bir ana "konuşlandırılmış" olarak bir geliştirme "özellik" dalında yapıldığını gördüm.

iş akışı şu şekilde sonuçlanır:

• bir şey kodla
• yerel testler yap
• çalışma şubesine giriş
• (isteğe bağlı) build server ant testleri oluşturur
• KG / İşletme testi
• hata düzeltmeleri (başa dön)
• şube dağıtmak için birleştirme
• dağıtmak

Bazı insanlar tek bir daldan çalışırlar, ancak zorlaşan manuel testler yapacaksanız. Çoğu kişi, tek bir bagajdan da işe yarayan herhangi bir şeyin küçük bir şey yaptığını veya büyük miktarda otomatik teste tabi tutulduğunu varsayarak ya da bu konuşmada "konuşlandırmayı" düşünüyor. bir test sunucusunun derlemesi olun ve test sunucusu ile üretim arasında gerçekleşen KG süreci ayrı ayrı ele alınır.

Aynı özellik dalında otomatik kabul testlerine sahibiz. Bir sürüm adayı yaptığınızda, özelliğin geçip geçmediğini görmek için çalıştırdığınız otomatik testleri içerir. Ayrıca sürüm adayını da test edersiniz. Her şey geçtiğinde, onu ustalaşmak için birleştirerek tanıtın.

Burada bu işlem hakkında daha fazla bilgi:

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

Yorumları da kontrol edin.

Bu yardımcı olur umarım,

Adem

Genel bir kural olarak, kod mükemmel olmadan önce işlemek için bekleyen sürüm kontrol sisteminin avantajlarını geri almak yarısıdır. (Çok fazla ayrıntıya girmeden, VCS'ye birden fazla check-in yapılmasına izin verilmedikçe, kendi çalışmamı geri döndürmenin bir yolu olmadığını söyleyebilirim!) Bu yüzden bir uygulama olarak insanlardan her zaman check-in yapmasını istiyoruz (SVN için şubelerinde) veya GIT durumunda yerel taahhütler olabilir). Aslında daha iyi.

Ancak, her şeyin nerede nokta geldiğinde görünür yapılması ve test edilecek - biz bir tahliye arayıp sonra da gövde ile birleştirilir. Esasen, KG HEADşubenin yeni bir kontrolünü yaparak RC'yi sertifikalandırabilir ve eğer Okey'in bunu yaparsa, aynı şey gövde ile birleştirilir.

Bu yüzden, aslında görev dalları veya özel kollar kavramını kullanıyoruz, böylece insanlar ihtiyaç duydukları kadar check-in yapabiliyorlar. Aynı zamanda, gövde nispeten olan serbest herhangi birinden kırık check-in işlemlerinde.