Web uygulamasını doğrudan SVN'den üretime dağıtmak kabul edilebilir mi?

Soru

Üretim dağıtımlarında SVN'yi KULLANMAMANIN meşru bir nedeni var mı , yoksa bu sadece kişisel tercih meselesi mi ve SVN'ye karşı gerçek bir dava yok mu?

Arka fon

Benim işyerim SVN içinde etiketleme sürümü bir kültür ve daha sonra bu üretim doğrudan kullanarak svn coveya svn switchdahil olmak üzere çeşitli web sunucularına doğrudan dağıtım kültürü vardır .

Bir derleme ve dağıtma komut dosyası veya bazı form veya otomatik dağıtım kullanmadan belgelenmedikçe tümleştirme ortamı ayarlarını kaybettiğinize inandığım için kişisel olarak bu konuda bir sorunum var. Ancak bundan daha fazlası, göz ardı edilen şeyi yapmak için gizli bir tehlike olabileceğini, henüz çirkin kafasını arkada bırakmayan bir şey olduğunu hissettim.

Çeşitli ortamlarımıza (evreleme, üretim öncesi, üretim) vb. Kod dağıtmaktan sorumlu operasyon personeli ile ilgili endişelerimi gündeme getirdim. Onların argümanları hemen hemen iyi çalıştı, değiştirmek için hiçbir neden yoktu.

Düzenle:

Oluşturma ve dağıtma hakkında ne demek istiyorum:

Örneğin, bir geliştirici belirli bir ortam için bir web.config ayarı eklenmesini gerektiriyorsa. Web.config genellikle svn'de tutulmaz ve bu nedenle bu dosyalar herhangi bir otomatik derleme betiği olmadan el ile güncelleştirilir. Kaybolurlarsa veya OPS, bir sürüm için web.config dosyasına bir alan eklemeyi unutursa, sorunlarınız vardır.

Belirli bir ortama uygun bir web.config dosyasını otomatik olarak oluşturmak için XMLPoke kullanan bir yapı komut dosyası, ortamlarınızın her biri için gerekli tüm değişiklikleri belgeleyen sürümlenebilir bir komut dosyanız olması açısından idealdir.

Mevcut Derleme ve Dağıtım Yöntemi

Söz konusu proje için bir geliştirici manuel olarak bir sürüm oluşturur, diğer projelerde NANT veya MSBuild ile otomatikleştirilmiş oluşturma adımı bulunur.

Çoğu proje için veritabanı geçişleri, DB komut dosyaları veya geçiş komut dosyaları (Migrator.NET) veya CMS Paketleri aracılığıyla gerçekleştirilir.

CI genellikle Team City tarafından check-in esasına göre yapılır, tüm biletlerin şubelerde yapıldığı ve daha sonra bagaja girmeden önce doğrulama ve doğruluk / kalite açısından akran tarafından incelenen bir kod inceleme sürecimiz vardır (iyi çalışır).

Bununla birlikte, gerçek kod dağıtımı, etiketli bir sürümün kontrol edilmesi veya daha genel olarak bir SVN Anahtarı yoluyla SVN aracılığıyla hemen hemen her zaman yapılır. Bu, depomuzu konuşlandırma sürecinin bir parçası olarak kullandığımız için garip bir şey.

Yapılandırma genellikle çok sık değişmez, yapılandırma dosyalarında olacak tek şey ortama özgü bilgilerdir. Diğer her şey db.

Beni yanlış anlamayın, bu işe yarar. Ancak otomatik bir derleme ve dağıtım için denemek ve itmek istiyorum. Bunu Rails ve Capistrano ile ve Cygwin, Nant ve SSH kullanan kişisel projeler için kullandım.

Daha da önemlisi, meslektaşlarımın Otomatikleştirilmiş bir derleme ve dağıtma yöntemine geçmelerini sağlamak için çok özel geçerli argümanlara ihtiyacım olacaktı.

Veya özellikle üretime dağıtmak için SVN kullanımına karşı gerçek geçerli hiçbir argüman YOK mudur?

Deneyimlerime göre, hem avantajlar hem de dezavantajlar var:

Artıları:

• Bazen üretim sunucusunda acil düzeltmeler yaparsınız, daha sonra bunları doğrudan oradan kontrol edebilirsiniz. (Teorik olarak, güvenlik nedenlerinden dolayı, üretim sunucusundan repoya salt okunur erişim kullanmak her zaman iyi bir fikirdir.)

• Basitlik: Hızlı bir şekilde teslim edersiniz, ancak burada belirtildiği gibi, bir güncelleme komut dosyası şemasına geçmek o kadar kolay olabilir.

Eksileri:

• Sisteminiz svn upve DB güncellemeleri sırasında kararsız hale gelebilir . Yüksek trafikli bir site için bu, bazı kullanıcıların en iyi hata mesajlarına, bozuk sayfalara veya boş sayfalara çarpacağı anlamına gelir. Çeşitli sosyal hizmetlerde sık sık gördüğümüz şey budur. Ancak iyi bir hizmet, sistemi bir güncelleme süresi boyunca bakım moduna geçirmesi bakımından "atomik olarak" yapar. ( Reddit'i kırdın! )

• Çatışmalar: yapım sunucusundaki ani çakışmaları çözmek korkunç bir fikirdir: yine, siz onarırken servis kararsız hale gelir.

• Üretim sunucusunda size ait olabilecek veya olmayabilir, ilgisiz dosyalar, ancak repodaki doğru alt ağacı kontrol ederek bundan kaçınabilirsiniz.

• Güvenlik: meşru olsun ya da olmasın, üretim sunucunuza erişim kazanmış biri de depolarınıza, muhtemelen diğer ürünlere ve muhtemelen de yazma erişimine erişir! Genel olarak dahili SVN sunucunuzu dış dünyaya açmak kötü bir fikirdir. Kaynak havuzlarınız bir şirketin güvenlik duvarının arkasında olmalıdır.

• Zaten güncelleme komut dosyaları olacak, örneğin DB yapısını güncellemek, cronjobs, vb yönetmek için, bu yüzden neden hepsini yapan bir komut dosyası yok? - yani en son paketlenmiş sürümü çeker, bakım moduna geçer, kaynakları günceller, sürüme özgü komut dosyaları çalıştırır vb.

Düzenleme: Hala SVN şemasında olanlar için, bunu apache yapılandırmanızda unutmayın:

<DirectoryMatch .svn>
    Order deny,allow
    Deny from all
</DirectoryMatch>

İşimde, birim testlerinin başarıyla geçtiğini varsayarak yükleyicimizi otomatik olarak oluşturan bir CI sunucusu kurdum. Yaklaşık bir günlük iş sürdü ve kurduğumdan beri beni bundan çok daha fazla kurtardı.

Sürüm / kurulumcu / üretim web sitenizi yapılandırırken herhangi bir manuel işlem varsa, kendinizi ve şirketinizin zamanından tasarruf edersiniz. Sorunuzdan kurulum işlemi sırasında manuel yapılandırma adımları varmış gibi görünüyor.

Referans için, Joel'in tek tıklamayla oluşturma sürecinin kısa ve orta vadede sizi nasıl kurtardığından bahsetmesine bakın .

SVN'de uygun check-in kontrollerine sahip olduğunuzdan emin olun. Örneğin, bunu düşünün -

• Özellikler bir sürüm için teslim edildi
• Kod evrelemeye yerleştirilir, KG işini yapar
• Hatalar düzeltildi, başka bir test turu (ancak ekibinizde çalışıyor)
• Üretim öncesi için Aynen
• Üretime dağıtım

Birisi yanlışlıkla üretim öncesi aşamadan sonra check-in yaparsa, bir şeyleri kırma riski vardır. Bu kontrol edilirse - hata düzeltmeleri hariç, ön üretim sırasında hiçbir checkin sırasında olduğu gibi - herhangi bir risk görmüyorum.

Güncelleme: Yapılandırma dosyalarınızı kontrol etmezseniz, oluşmayı bekleyen bir sorununuz var. Bunun için "lütfen yap ve hızlı!" Dışında herhangi bir öneri sunamıyorum.

Depo dışında hiçbir şey olmadığı sürece Tamam görünüyor. Aslında, projenin ilk birkaç ayında dağıtım araçlarına zaman harcamaması gerektiğine inanıyorum. Çünkü çok fazla dağıtım olacak, resmi bir sürüm sürecinden rahatsız olmak için yeterli müşteri yok.

Ancak proje yaklaşık bir yaşında olduğunda, dağıtım aracına yatırım yapmayı düşünmeye değer. Basit nedenler

• İş büyüdükçe birden fazla sunucuda barındırmayı planlıyorsunuz
• Belirli bir ortamda hatalar olabilir ve hatayı çoğaltmak için herhangi bir yeriniz yoktur. Bir tar-untar-forget_about_home_for_a_week işlemi olmadan kurmanın kolay bir yolu yoktur.
• Bazılarının yapıyı kırması muhtemeldir. Yapıyı kim kırdı

Onları ikna etmek istiyorsanız, dahili test veya KG için başka bir sunucu kurmalarını isteyin.