Şirketimizde geliştirdiğimiz bir e-ticaret uygulamamız var. Yaklaşık 3 yıldır açık ve kapalı olarak geliştirdiğimiz makul standart bir LAMBA uygulamasıdır. Uygulamayı bir test alanında geliştiriyoruz, burada yeni özellikler ekliyoruz ve hataları düzeltiriz. Hata izleme ve özellik geliştirmemiz barındırılan bir alt çözüm çözümü (unfuddle.com) içinde yönetilir. Hata bildirildiği gibi biz bu düzeltmeleri test etki alanı üzerinde yapmak ve sonra biz mutluyuz svn değişiklikleri düzeltildi hata düzeltildi. Aynı prosedürü yeni özelliklerin eklenmesiyle takip ediyoruz.
Sunucularımızın genelindeki sistemimizin ve uygulamamızın genel mimarisine dikkat çekmeye değer. Her yeni özellik geliştirildiğinde, bu güncellemeyi uygulamamızı (her zaman kontrol ettiğimiz bir sunucu) kullanarak tüm sitelere sunuyoruz. Sistemimizi kullanan her site, kod tabanının% 95'i için tamamen aynı dosyaları kullanır. Her site içinde o siteye özel dosyalar içeren birkaç klasör var - css dosyaları / resimler vb. Bunun dışında, her site arasındaki farklar her site veritabanındaki çeşitli yapılandırma ayarları ile tanımlanır.
Bu, gerçek dağıtımın kendisine geçer. Bir tür güncellemeyi kullanıma sunmaya hazır olduğumuzda ve test sitesinde bulunduğu sunucuda bir komut çalıştırıyoruz. Bu, bir kopyalama komutu (cp -fru / testsite / / othersite /) gerçekleştirir ve dosyaları değiştirilen tarihe göre güncelleyen her vhost kuvvetinden geçer. Barındırdığımız her ek sunucunun üretim kod tabanını yeniden senkronize ettiğimiz bir hayaleti var ve daha sonra kopyalama işlemini bu sunucudaki tüm sitelerde tekrarlıyoruz. Bu işlem sırasında üzerine yazmak istemediğimiz dosyaları, kopya tamamlandığında geri taşıyoruz. Açılış komut dosyamız, her veritabanını değiştirmek için SQL komutları uygulamak, alanlar / yeni tablolar eklemek vb. Gibi bir dizi başka işlevi yerine getirir.
İşlemimizin yeterince kararlı olmadığı, hataya dayanıklı olmadığı ve aynı zamanda bir kaba kuvvet yöntemi olduğu konusunda giderek daha fazla endişe duyduk. Ayrıca, yeni bir özellik üzerinde çalışmanın, dallardan veya etiketlerden faydalanmadığımız için önemli bir hata düzeltmesini önleyeceğimiz bir konuma sahip olduğumuz için yıkımı en iyi şekilde kullanmadığımızın farkındayız. Ayrıca, sunucularımız arasında çok fazla dosya çoğaltmamız olduğu da yanlış görünüyor. Ayrıca, daha yeni sunduklarımız için kolayca geri alma gerçekleştiremiyoruz. Her bir sunumdan önce bir fark yapıyoruz, böylece değiştirilecek dosyaların bir listesini alabiliriz, böylece neyin sonra değiştirildiğini biliyoruz, ancak geri alma işlemi hala sorunlu olacaktır. Veritabanı açısından potansiyel bir çözüm olarak dbdeploy içine bakmaya başladım. Gerçekten istediğimiz şey, dosya yönetimimizi ve dağıtımımızı nasıl geliştirebileceğimiz hakkında bazı genel rehberliktir. İdeal olarak, dosya yönetiminin depomuza daha yakından bağlanmasını istiyoruz, böylece bir geri alma / geri alma svn'ye daha fazla bağlı olacaktır. Site dosyalarının repo dosyalarıyla aynı olduğundan emin olmak için export komutunu kullanmak gibi bir şey. Çözüm de sunucularımızdaki dosya çoğaltmasını durdurabilirse de iyi olurdu.
Mevcut yöntemlerimizi göz ardı etmek, diğer insanların aynı soruna nasıl yaklaştığını duymak gerçekten iyi olurdu.
özetle ...
- Birden fazla sunucudaki dosyaları svn ile senkronize halde tutmanın en iyi yolu nedir?
- Dosya çoğaltmayı nasıl engellemeliyiz? sembolik bağlar / başka bir şey?
- Yeni özellikleri geliştirip eski özellikleri düzeltebilmemiz için repoumuzu nasıl yapılandırmalıyız?
- Rollouts / rollback'leri nasıl tetiklemeliyiz?
Şimdiden teşekkürler
DÜZENLE:
Son zamanlarda bu tür görevler için Phing ve Capistrano'yu kullanma hakkında çok iyi şeyler okudum . Herkes onlar hakkında daha fazla bilgi verebilir ve bu tür bir görev için ne kadar iyi olurdu?