Kod dağıtmak için her zaman çok basit bir bash betiği kullandım. Subversion kullanmaktan Mercurial'a geçiyorum ama revizyon kontrol yazılımının konuşlandırma için önemli olduğunu sanmıyorum.
Bunu yapmanın bazı daha iyi yolları nelerdir?
#!/bin/sh
date=`date +%Y%m%d_%H%M%S`
tar -zcvf app-dir-$date.tar.gz app/dir
tar -zcvf app-templates-$date.tar.gz app/templates
tar -zcvf app-media-$date.tar.gz app/media
svn export http://example.com/somepath/trunk hh/ --force
Statik HTML sayfalarım dahil her şeyi yönetmek için Mercurial kullanıyorum. Hayatı gerçekten çok kolaylaştırıyor, benim için çok kolay.
Avantajlar arasında
Yasal Uyarı, öğretici yazdım. Evet, kullandığınız VCS türü bir dereceye kadar önemlidir. Örneğin, bu senaryoda yerel olarak işlem yapamadığım ve büyük bir İtme/güncelleme yapamadığım bir şey kullanmazdım. Bu sadece beni bir sorun haline getirebilecek çok fazla potansiyel sorunlu değişiklik yapmaya zorluyor.
Ben Subversion ile yapabilir ve SVN'yi hiçbir şekilde çalmıyorum. Sadece Mercurial'ın çözmeye çalıştığınız problem için çok daha iyi bir araç olduğunu düşünüyorum.
Benim başka bir seçeneğim yoksa araçların üzerinde 'çalışmak' zorunda değilsin. Bu şekilde yapmak, onlara sahip olma amacını yitirir ve bir seçeneğiniz vardır :)
Diğer cevaplardaki mükemmel önerilere ek olarak, atomik bir güncelleme yapmanın sizin için önemli olup olmadığını düşünebilirsiniz.
FreeBSD sunucumda bunu iki mekanizma ile yapıyorum:
Tüm statik kaynaklarımın sürümlerini oluşturma. (Örneğin, http://static.example.com/images/logo.1.png
veya http://static.example.com/style/main.3.css
). Bu, kullanıcıları eski sayfalarda yeni dosyalar görmekten endişe etmeden, dinamik siteyi güncellemeden hemen önce statik siteyi svn update
sağlar.
Tüm dinamik web sitesinin versiyonlanması. Benim durumumda, doküman köküm sembolik bir bağlantıya işaret ediyor. Stratejim, yeni üretim versiyonunu devreye sokmak ve ardından tek bir komutla canlı yayınlamak. .g. böyle bir şey:
cp -Rp www.site1.com.1 www.site1.com.2
(veya svn checkout
)
svn update site1.com.2
(önce bir svn switch
gerekir)
ln -sf site1.com.2 www.site1.com
(değişiklikleri üretime atomik olarak taşı)
Bu, hiçbir kullanıcının yarı pişmiş bir sayfa görmemesini sağlar. Hala önbellekte ise eski sürümü ya da yenisini görecekler.
Bu strateji, yalnızca kullanıcı tarafından yüklenen içeriği dinamik sitenizle karıştırmamanız durumunda işe yarar.
Karıncaları scp görevi , değiştirilmiş seçici ile kullanırız. Bu, önceki yüklemeden bu yana değişen dosyaları güncellemeniz anlamına gelir. Ne yazık ki, değiştirilmiş seçicinin yalnızca kişisel kullanım için tasarlandığı, ekip üyeleriyle paylaşmadığı anlaşılıyor. cache.properties
dosyasında, kullanıcının çalışma dizinine giden yol adları bulunur. cache.properties
dosyasını, geliştiriciler arasında paylaşılabilecek bir formatta, daha sonra da karıncaların ihtiyaç duyduğu formata sokulacak bir formatta masaj yapmak için bir grup karınca hedefi yazdık. Format ayrıca bir Windows ortamı ve bir GNU/Linux ortamı arasında da değişiklik gösterir.
Sürüm kontrolünü kullanmanın amacı, bir güncelleme yapmadan önce siteyi yedeklemekle ilgilenmenize gerek yok mu?
Doğru şekilde yapılırsa, bir svn update
(veya eşdeğeri) yeterli olmalı ve eğer bir hata olursa bir önceki işleme geri döndürülsün mü? Her nasılsa biz yapıyoruz. Tüm değişiklikleri yapın, svn update
aşamalandırma sunucusu, hepsi tamamsa o zaman svn update
canlı sunucu.