Mercurial'ı sunucunuza yüklemek ve hg pull'u dağıtmak iyi bir fikir mi?

Ben sadece geçen ay yeni bir iş başladım ve kodları için hiçbir kaynak kontrolü var gibi görünüyor. Onlar kendi barındırma sağlayıcısı onlar için alır yedekleri güveniyor.

Biraz konuştuktan sonra patronumu kesinlikle kaynak kontrolü kullanmamız gerektiğine ikna ettim ve üzerinde kısa bir seminer verdikten sonra tüm ekip gemide; Mercurial'ı sevdiler.

Şimdi şu şekilde çalışıyoruz:

º----------BitBucket
º---------/
º--------/

Ben ve hg pullBitBucket'ten üç geliştirici daha sonra hg pushBitBucket'te değişiklikler yapıyor.

Şimdi dağıtım için, birinin en son dosyaları üretim sunucusuna doğru FTP'ye göndermesi gerekir.

Mercurial'ı sunucumuza kurmayı ve hg clone(daha sonra hg pull) sürümleri üretimde güncel tutmak için kullanmayı düşünüyordum .

º---push->-----BitBucket----<-pull-----º (production server)
º---push->----/
º---push->---/

Bu iyi bir fikir mi? Göremediğim potansiyel tuzaklar var mı? Burada kimse benzer bir şey yaptı mı? Büyük bir PHP framework uygulamasını nasıl dağıtırsınız (Moodle kullanıyoruz)?

Bu kesinlikle iyi bir fikirdir ve dağıtım için kullanılan yaygın bir yöntemdir. Stabil şubeyi üretime dağıtmadan önce test edebilmeniz için gövdeyi sürekli geliştirme için tutarken, dağıtım amaçları için kararlı bir dal kullanmak isteyebilirsiniz.

Tek sorun, kod tabanınızda (API anahtarları vb.) Üçüncü taraf sunuculara yüklemek istemediğiniz (örneğin, Bitbucket) hassas bilgileriniz olduğunda ortaya çıkabilir. Bu durumda, hassas verileri doğru yere geri yüklemek için verileri depodan aldıktan sonra çalıştırılan basit bir komut dosyası bu sorunu çözecektir.

Bu dağıtım stratejisinin atomik olmadığını unutmayın. Bazı dosyalar zaten güncellenmiş olabilir, diğer dosyalar ise uygulama vurulurken hala eski durumda olabilir. Bu beklenmedik yan etkilere neden olabilir.

Atomik konuşlandırmalar yapmanın bir yolu, sembolik bağlantıları kullanmaktır. Yeni dosyaları içeren bir dizin oluşturun. everthing hazır olduğunda kullanılan dizin için bir symlink değiştirin. Eski sürümü saklarsanız kolayca geri alabilirsiniz.

Başka bir (bence daha iyi) olasılık: bir yapı sunucusu / sürekli entegrasyon sunucusu kullanın.

Kısa kısa açıklama: Bu, depolarınızı izlemek için ayarladığınız bir sunucudur (şirket içinde olabilir, internette olması gerekmez) ve depolarda yeni değişiklik kümeleri olduğunda, sunucu kodunuzu oluşturur ( AFAIK bu PHP'de gerekli değildir) , birim testleri çalıştırır ve kodunuzu web sunucusuna dağıtır.

Daha fazla bilgi için şu bağlantıları kontrol edin:

• CI hakkında Wikipedia makalesi
• Yığın Taşması sorusu: “Derleme Sunucusu” nun anlamı nedir?

Orada CI için birçok farklı ürün var , ancak şimdiye kadar kullandığım tek şey TeamCity . Kurulumu çok kolay ... aslında, denediğim ilk şey ve onu çok sevdim, ona bağlı kaldım.

Alternatif ucuz çözüm:

Bir yapı sunucusu kurmak çok fazla çaba harcıyorsa veya sitenizin tam olarak ne zaman dağıtıldığı konusunda daha fazla kontrol istiyorsanız , yalnızca bir komut dosyası (Windows'ta Batch / Powershell veya Linux / Mac'te benzer bir şey) ayarlayın . deponuzdan en yeni sürümü ve üretim sunucusunda FTP'leri.

Temel olarak, bir yapı sunucusu ile aynı, sadece daha basit.

Sonunda tam olarak nasıl çözerseniz seçin ... bir şekilde otomatikleştirdiğinizden emin olun!

Tek bir tıklamayla / tek bir komut yazarak dağıtabilirsiniz, böylece HERKES özel bir şey bilmeden ve hata yapmadan - bir felaket durumunda veya stres altında olsa bile bunu yapabilir.

Bunu ya da buna benzer şeyleri yapıyoruz. Atomik olmayan @johannes'in açısı bir meseledir, ancak gerçekçi terimlerle bu kadar hızlı gerçekleşir, ancak Tamam olmalıdır ve işaret ettiği gibi bunun etrafında yollar vardır.

Muhtemelen bu atomik olmayanlıktan daha önemli olan "veritabanı şeması güncellemelerini nasıl yönetirsiniz" olacaktır - kötü kodu bu şekilde dağıtmak, düzeltmeyi kolaylaştırır. Büyük sorun, geri almak istediğiniz veritabanını değiştiren bir güncelleştirme dağıtmanızdır. Veya kötü güncellemeler yapıyor ve verileri bozuyorsanız.

DCVS araçlarıyla ilgili diğer bir sorunumuz (SVN kullanmak yerine), artık bir saldırganın potansiyel olarak yakalayabileceği bir yerde makinedeki tüm kod tabanının bir kopyasına sahip olmanızdır. Ayrıca, DCVS kod tabanının boyut olarak oldukça ağır olabileceğinden, depolama ve / veya yedekleme için ödeme yapmanız önemli olabilir. Bu nedenlerden dolayı son dağıtım için hala SVN kullanıyoruz.

Harika bir fikir, ancak aşağıdakileri unutmayın:

• Sunucuya bağlı kalmamaya çalışın (nadiren de olsa bunu yapmak mantıklı olsa da, örneğin bir eklenti yüklemek veya içerik öğeleri eklemek)
• Test için bir hazırlama sunucusu veya ikincil bir depo dağıtımı kullanma
• hg update -CÜretimi etkilememesine dikkat edin (önemli dosyaları silin)
• Bir üretim ve geliştirme şubesine sahip olun, sadece üretim şubesini dağıtın
• Varlıklara yedek olarak davranma (ör. İçerik için resimler) ve kullanıcı verilerini (ör. Ekler / yüklemeler, önbellek, vb.) Yoksay
• hg statusSunucuda her zaman temiz bir çıktı alın (bu, şeyleri önbellek olarak yok saydığınızdan emin olmanıza yardımcı olacaktır)
• Havuzu web klasörüne dağıtmayın. Kamusal alanın dışından semboller kullanın (örn. Ln -s / myrepo / src / web / public_html / myapp)
• Konfigürasyon dosyalarını versiyon etmemeye dikkat edin (özellikle veritabanı şifreleri veya diğerleriyle)
• Üretim yedeği yerine kullanmayın, bu üretim verileri için değil, üretim kodu için bir geliştirme yedeğidir.

Son olarak, dağıtım işleminize bir DVCS eklemek için en değerli şeyin, dağıtımınıza güvenlik katacağı, bazen bilgisayar korsanlarının dosyalarınıza kötü amaçlı kod enjekte ettiği ve sürüm kontrolü gibi bir şey olmadan kolayca tespit etmenin hiçbir yolu olmadığını düşünüyorum. VCS'nin dağıtılmış yönü dosyalarınızın bütünlüğünü kontrol etmeyi kolaylaştırdığından, özel olarak dağıtılır).

Ben kazanılmış bazı siteler Mercurial bana yardımcı olan, bir kaç kez kesmek yaşadım litterally sadece düzenlenmek suretiyle bu kesmek geri hg update -C(bir yapmak isteyebilirsiniz elbette sunucusunda hg statusve sonraki analiz için etkilenen dosyaları almak).