Tercih ettiğiniz php dağıtım stratejiniz nedir? [kapalı]

PHP'de yeni bir projeye başlıyorum ve diğer geliştiricilerden PHP dağıtımı için tercih ettikleri strateji hakkında geri bildirim almak isterim. İşleri biraz otomatikleştirmek isterim, böylece değişiklikler yapıldıktan sonra hızlı bir şekilde bir geliştirme veya üretim sunucusuna geçebilirler.

Capistrano'yu Ruby ile birlikte kullanmanın yanı sıra bazı temel kabuk komut dosyası oluşturma deneyimim var.

Önce kendi başıma dalmadan önce, başkalarının projelerinde buna nasıl yaklaştığını duymak harika olurdu.

Daha fazla bilgi

Şu anda geliştiriciler sitenin yerel kurulumları üzerinde çalışıyor ve bir yıkım deposunda değişiklik yapıyorlar. İlk dağıtımlar etiketlenmiş bir sürümü svn'den dışa aktarıp sunucuya yükleyerek yapılır.

Ek değişiklikler genellikle değiştirilen dosyaları manuel olarak yükleyerek parça parça yapılır.

PHP için, Phing derleme komut dosyalarına sahip SVN gitmek için bir yoldur. Phing benzer ANT ama çok daha kolay PHP geliştiricileri kendi ihtiyaçları için değiştirmek için yapar PHP, yazılmıştır.

Dağıtım rutinimiz aşağıdaki gibidir:

• Herkes işyerinde aynı yerel sunucu üzerinde gelişir, her geliştiricinin makinesinde de bir ödeme kutusu vardır.
• Taahhütler, bir hazırlama sunucusunu güncelleyen bir işlem sonrası kancayı tetikler.
• Testler, geçerlerse, hazırlama sunucusunda yürütülür - devam et.
• Phing derleme çalıştırıldı:
• Alan adını bir "Yapım aşamasında" sayfasına geçirerek üretim sunucusunu kapatır
• Üretim kontrolünde SVN güncellemesi çalıştırır
• Şema delta komut dosyasını çalıştırır
• Testleri gerçekleştirir
• Testler başarısız olursa - geri alma komut dosyasını çalıştırın
• Testler geçerse, sunucu üretim kontrolüne geri döner

Bir Sürekli Entegrasyon sunucusu olan phpUnderControl de var . Web projelerinin dürüst olmasını çok yararlı bulmadım.

Şu anda Git kullanarak PHP dağıtımı yapıyorum . Üretim sunucumu Git'in en son kopyasıyla güncellemek için basit bir git push üretimi yeterlidir. Kolay ve hızlı çünkü Git tüm projeyi değil, sadece diffs'leri gönderebilecek kadar akıllı. Sonunda donanım arızası olması durumunda, deponun yedek kopyasının web sunucusunda tutulmasına yardımcı olur (yine de güvenli olmak için GitHub'a da basarım).

Capistrano için bir web ön ucu olan Webistrano'yu kullanıyoruz ve bundan çok memnunuz.

Webistrano, SVN, GIT ve diğerlerinden çok aşamalı, çok ortamlı dağıtımlara izin verir. Yerleşik geri alma desteği, web, db, uygulama vb. Gibi ayrı sunucu rolleri desteği vardır ve paralel olarak dağıtılır. Aşama başına gibi birden çok düzeyde yapılandırma parametrelerini geçersiz kılmanıza olanak tanır ve isteğe bağlı olarak posta yoluyla her dağıtımın sonuçlarını günlüğe kaydeder.

Capistrano ve Webistrano Ruby uygulamaları olsa da, dağıtım 'tariflerin' sözdizimi herhangi bir PHP programcısı için anlaşılması kolay ve güçlüdür. Başlangıçta Capistrano, Ruby on Rails projeleri için üretildi, ancak PHP projelerini kolayca barındırıyor.

Bir kez konfigüre edildikten sonra, bir hazırlama versiyonunu dağıtan test ediciler gibi programcı olmayanlar tarafından kullanılmak bile kolaydır.

Mümkün olan en hızlı dağıtımı sağlamak için , uzak sunucudaki bir svn çalışma kopyası önbelleğini güncelleyen fast_remote_cache yöntemini yükledik ve ardından sonucu zorlaştırdık.

Apache Ant'i farklı hedeflere (dev, QA ve live) dağıtmak için kullanıyorum . Ant, Java dağıtımı için çalışacak şekilde tasarlanmıştır, ancak rasgele dosyaları dağıtmak için oldukça kullanışlı bir genel durum çözümü sağlar.

Build.xml dosyasının sözdizimini öğrenmek oldukça kolaydır - komut satırında ant programını çağırdığınızda çalışan farklı hedefleri ve bağımlılıklarını tanımlarsınız.

Örneğin, her biri CVS sunucumuzdan en son kafa revizyonunu kontrol eden cvsbuild hedefine bağlı olan dev, QA ve live için hedeflerim var, uygun dosyaları derleme dizinine kopyalar (dosya kümesi etiketini kullanarak) ve sonra Yapı dizinini uygun sunucuya rsyncs. Öğrenmek için birkaç tuhaflık var ve öğrenme eğrisi tamamen düz değil, ama bunu yıllardır sorunsuz bir şekilde yapıyorum, bu yüzden durumunuz için tavsiye ederim, ancak başka cevapların ne olduğunu merak ediyorum Bu konuda görüşürüz.

Git kullanarak elle bir şeyler yaparım. git push --mirrorKamuya açık bir repo düzenleyen geliştirme için bir depo ve canlı sunucu bundan çıkarılan üçüncü bir repo. Sanırım bu bölüm kendi kurulumunuzla aynı.

En büyük fark, üzerinde çalıştığım hemen hemen her değişiklik için şubeler kullanmam (şu anda yaklaşık 5 tane aldım) ve aralarında ileri geri dönme eğilimindeler. Ana dal, diğer dalların birleştirilmesi dışında doğrudan değişmez.

Canlı sunucuyu doğrudan ana daldan çalıştırıyorum ve başka bir dalla bitirip birleştirmeye hazır olduğumda, sunucuyu bir süreliğine bu şubeye çevirin. Eğer kırılırsa, master'a geri döndürmek saniyeler alır. Çalışırsa, master ile birleştirilir ve canlı kod güncellenir. SVN'de bunun bir benzetmesinin iki çalışma kopyası olacak ve canlı olanı bir symlink aracılığıyla işaret edeceğini düşünüyorum.

Phing şimdi birkaç kez bahsedildi biliyorum , ama phpUnderControl ile büyük şans oldu . Bizim için biz

1. Şubelerin yerel makinelere tek tek kopyalarını inceleyin
2. Dallar test edilir ve daha sonra Trunk ile birleştirilir
3. Bagaj taahhütleri otomatik olarak phpUnderControl tarafından oluşturulur, testleri çalıştırır ve tüm belgeleri oluşturur, veritabanı deltalarını uygular
4. Gövde kalite testinden geçirilir ve daha sonra Kararlı şubemize birleştirilir
5. Yine phpUnderControl otomatik olarak Stable oluşturur, testleri çalıştırır ve dokümantasyon ve güncelleme veritabanı oluşturur
6. Üretime aktarmaya hazır olduğumuzda, Üretim'i yedekleyen, veritabanını güncelleyen ve daha sonra dosyaları yukarı iten bir rsync betiği çalıştırıyoruz. Birinin promosyonu izlediğinden emin olmak için rsync komutu elle çağrılır.

ev yapımı dağıtım komut dosyalarına bir alternatif, bu işin çoğunu sizin için soyutlayan hizmet olarak bir platforma dağıtmaktır. PaaS tipik olarak kendi kod dağıtım aracını ve ölçekleme, hataya dayanıklılık (örn. Donanım arızalandığında aşağı gitmeme) ve genellikle izleme, günlük kontrolü vb. İçin harika bir araç seti sunacaktır. zaman içinde güncel tutulacak bilinen iyi yapılandırma (sizin için daha az baş ağrısı).

Ben tavsiye ederim PaaS dotCloud , PHP ek olarak ( onların PHP hızlı başlatma bakın ) aynı zamanda MySQL, MongoDB ve bir sürü ek hizmet dağıtabilirsiniz. Ayrıca sıfır kesinti süresi dağıtımı, anında geri alma, SSL ve websocket için tam destek, vb.Gibi güzel güzellikler var. Ve her zaman güzel olan ücretsiz bir katman var :)

Tabii orada çalıştığımdan beri biraz önyargılıyım! DotCloud'a ek olarak kontrol edilmeye değer diğer seçenekler Pagodabox ve Orchestra (şimdi Motor Yard'ın bir parçası).

Bu yardımcı olur umarım!

Solomon

Bir depodan üretim sunucularına otomatik ve körü körüne değişiklik yapmanız tehlikeli görünebilir. Taahhütlü kodunuz bir regresyon hatası içeriyorsa, üretim uygulamanız hata verirse ne olur?

PHP için Sürekli Entegrasyon sistemi istiyorsanız, Phing PHP için en iyi seçimdir sanırım . Ben kendimi test etmedim, ancak, örneğin scp manuel yol şeyler yapmak gibi.

Partiye geç kaldım ama yöntemlerimizi paylaşacağımı düşündüm. Phing'i , Phing'e önceden oluşturulmuş derleme dosyaları aracılığıyla Capistrano benzeri işlevsellik sağlayan Phingistrano ile kullanıyoruz . Çok güzel, ama sadece Git'i şu anda kullanıyorsanız işe yarar.

Sunucuda bir SVN yayın şubesinin çalışan bir kopyası var. Siteyi güncellemek (şema değişiklikleri olmadığında) bir SVN güncelleme komutu vermek kadar kolaydır. Siteyi çevrimdışına almak zorunda bile değilim.

Phml yapılandırma dosyalarının acısına dayanabilirseniz, Phing muhtemelen en iyi seçimdir. Symfony çerçevesinin oldukça iyi çalışan kendi tırmık limanı (pake) vardır, ancak Symfony'ın geri kalanına oldukça sıkı bağlıdır (Muhtemelen onları ayırabilirsiniz).

Başka bir seçenek Capistrano kullanmaktır. Açıkçası, Ruby ile olduğu gibi PHP ile de entegre olmuyor, ancak yine de birçok şey için kullanabilirsiniz.

Son olarak, her zaman kabuk komut dosyaları yazabilirsiniz. Şimdiye kadar bunu yaptım.

http://controltier.org/wiki/Main_Page

bunu çoklu sunucu dağıtımları ve bakımı için kullanacağız.

Bir yıl geç ama ... Benim durumumda dağıtım otomatik değil. Kod dağıtmayı ve veritabanı geçiş komut dosyalarını otomatik olarak çalıştırmayı tehlikeli buluyorum.

Bunun yerine, alt sürüm kancaları yalnızca test / evreleme sunucusuna dağıtmak için kullanılır. Kod, testler yaptıktan ve işlerin çalışacağından emin olduktan sonra, bir yinelemenin sonunda üretime dağıtılır. Dağıtımın kendisi için, dosyaları aktarmak için rsync kullanan özel yapım bir Makefile kullanıyorum. Makefile uzak sunucuda geçiş komut dosyalarını çalıştırabilir, web ve veritabanı sunucularını duraklatabilir / devam ettirebilir.

İşimde kendim ve ekibim capistrano'nun konuşlandırılması için Phing odaklı bir yedek geliştirdik ve PHPUnit testi, phpcs ve PHPDocumentor gibi phing'de bulunan bazı güzellikleri de dahil ettik. Git'te bir alt modül olarak bir projeye eklenebilen bir git repo yaptık ve çok iyi çalışıyor. Bir avuç projeye ekledim ve çeşitli ortamlarımızdan herhangi birinde (evreleme, test, üretim vb.) Herhangi bir projeyle çalışmasını kolaylaştıracak kadar modüler.

Phing derleme komut dosyaları ile bunları komut satırından manuel olarak çalıştırabilirsiniz ve ayrıca Hudson ve şimdi Jenkins ci ile derleme / dağıtma rutinlerini otomatikleştirmede başarılı oldum.

Repo henüz herkese açık olmadığı için şimdi herhangi bir bağlantı gönderemiyorum, ancak bazen yakında açık kaynak yapacağımız söylendi, bu yüzden lütfen ilgileniyorsanız veya varsa phing ve git ile dağıtımınızı otomatikleştirmeyle ilgili sorularınız varsa.

Sanırım SVN konuşlandırma yolu çok iyi değil. Çünkü:

Tüm dünya için SVN erişimini açmanız gerekiyor

üretim web sunucularında birçok .svn var

Ben bir şube üretmek için Phing + tüm www sunucularına tüm yapılandırma js / css + yerine config + ssh upload birleştirmek daha iyi bir yol olduğunu düşünüyorum.

ssh to 10 www server ve svn up da sorun.