Composer'in geliştirme / üretim anahtarını kullanırken doğru şekilde nasıl konuşlandırılır?

180

Composer, yalnızca geliştirme aşamasındayken birkaç bağımlılık yükleme seçeneğine sahiptir, bu nedenle araçlar üretimde (canlı sunucuda) yüklenmez. Bu (teoride), testler, sahte veri araçları, hata ayıklayıcı vb.Gibi yalnızca geliştirmede anlamlı olan komut dosyaları için çok kullanışlıdır.

Gidilecek yol, geliştirmede require-devihtiyacınız olan araçlarla ek bir blok eklemektir :

"require-dev": {
    "codeception/codeception": "1.6.0.3"
}

ve sonra (teorik olarak) bu bağımlılıkları

composer install --dev

Sorun ve Soru:

Composer, 2013'ün davranışını değiştirdi installve updateönemli ölçüde, require-devbağımlılıklar artık varsayılan olarak yüklendi (!), Bir require-devblokla composer.json oluşturmaktan ve composer installyeniden üretmek için bir gerçekleştirmekten çekinmeyin .

Konuşlandırmanın en kabul edilen yolu besteciyi itmektir. kilitleyin (mevcut besteci kurulumunuzu tutar) ve ardından composer installüretim sunucusunda bir işlem yapın, bu da geliştirme öğelerini yükleyecektir.

Bu dağıtmak için doğru yolu nedir olmadan -dev bağımlılıkları yükleme?

_{Not: Burada tuhaf Besteci dağıtımını açıklığa kavuşturmak için standart bir Soru / Cevap oluşturmaya çalışıyorum. Bu soruyu düzenlemekten çekinmeyin.}

php deployment composer-php

— sliq
kaynak

@all: Ödülün nerede olduğunu bilmiyorum :( Başka bir yaklaşıma başlayacağım.

— Sliq

1

Eğer aktif olarak ödüllendirmezseniz ve hiçbir cevap kabul edilmez veya yeterince oy almazsa, kimse ödül alamaz.

— Sven

2

Ben şahsen bu yaklaşımı hiç sevmiyorum. composer.lock, Git repoya ASLA ilave edilmemelidir. Doğru yaklaşım, besteleyici güncellemesini hazırlamada kullanmak ve daha sonra dosyayı üretime senkronize etmektir (her şey işe yararsa, elbette). Evreleme, bir üretim ortamının tam kopyası olmalıdır. composer.lockparçası olmalıdır .gitignore.

— isim

6

composer.lock kesinlikle CSV'nize dahil edilmelidir !!! Nasıl herkes aynı sürümü kullandığınızdan emin olun ?? Bu yüzden ASLA composer.lock dosyasını CSV'nizden hariç tutmayın !!!

— Tobias Gaertner

3

@TobiasGaertner Sanırım VCS (sürüm kontrol yazılımı) demek istediniz, aksi takdirde projenin resmi önerileri doğrultusunda doğru ve aynı doğrultudasınız .

— Xiong Chiamiov

327

Neden

IMHO'nun Composer'ın --dev bugünlerde bayrağı varsayılan olarak (yükleme ve güncelleme sırasında) . Composer çoğunlukla bunun istenen davranış olduğu senaryolarda çalıştırılır:

Temel Composer iş akışı aşağıdaki gibidir:

Yeni bir proje başlatıldı: composer.phar install --dev json ve kilit dosyaları VCS'ye devredildi.
Diğer geliştiriciler proje üzerinde çalışmaya başladı: VCS ve composer.phar install --dev .
Bir geliştirici bağımlılık ekler:, composer.phar require <package>ekle--dev paketi require-devbölümde istiyorsanız (ve taahhütte bulun) .
Diğerleri: (ödeme ve) composer.phar install --dev .
Bir geliştirici daha yeni bağımlılık sürümleri ister: composer.phar update --dev <package> (ve taahhüt).
Diğerleri: (ödeme ve) composer.phar install --dev .
Proje konuşlandırıldı: composer.phar install --no-dev

Gördüğünüz gibi --dev--no-dev bayrak, özellikle projede çalışan geliştiricilerin sayısı arttığında bayraktan çok daha fazla kullanılır .

Üretim dağıtımı

"Dev" bağımlılıklarını yüklemeden bunu dağıtmanın doğru yolu nedir?

Peki composer.jsonve composer.lockdosyası VCS'ye bağlı olmalıdır. composer.lockKullanılmaması gereken paket sürümleri hakkında önemli bilgiler içerdiğinden atlamayın .

Bir üretim dağıtımı gerçekleştirirken, --no-devbayrağı Composer'a iletebilirsiniz :

composer.phar install --no-dev

composer.lockDosya dev-paketleri hakkında bilgiler içerebilir. Bu önemli değil. --no-devBayrak emin olanlar dev-paketleri yüklü değil yapacaktır.

"Üretim konuşlandırması" dediğimde, üretimde kullanılmayı amaçlayan bir konuşlandırmayı kastediyorum. Ben bircomposer.phar installBir üretim sunucusunda şeylerin gözden geçirilebileceği bir hazırlama sunucusunda yapılması gerektiğini tartışmıyorum. Bu cevabın kapsamı bu değildir. Ben sadece composer.phar install"dev" bağımlılıklarını kurmadan nasıl yapacağımı işaret ediyorum .

Konu dışı

--optimize-autoloaderBayrak da üretime uygun olabilir (sizin uygulamanızda hakklı hızlandırır bir sınıf harita oluşturur):

composer.phar install --no-dev --optimize-autoloader

Veya otomatik dağıtım tamamlandığında:

composer.phar install --no-ansi --no-dev --no-interaction --no-plugins --no-progress --no-scripts --no-suggest --optimize-autoloader

Kod tabanınız destekliyorsa, --optimize-autoloaderiçin takas edebilirsiniz --classmap-authoritative. Daha fazla bilgi burada

— Jasper N. Brouwer
kaynak

5

Bir istisna dışında söylenenlerin çoğuna katılıyorum. "composer install --no-dev" yalnızca bir hazırlama ortamında yürütülmeli ve bu ortamın değişmez olduğu düşünülmelidir. Üretim sunucumda ve önizleme / evrelemeden herhangi bir bağımlılığın doğrudan indirilmesini istemem. Bu sadece biraz dikkat.

— Ölçeklenebilir

3

@Scalable: Size katılıyorum (ve Sven bunu cevabında güzel bir şekilde ele alıyor), bu cevabımın kapsamı değil, "üretim dağıtımı" ile kastettiğim şey değil. Bunu netleştirmek için bir paragraf ekledim.

— Jasper N. Brouwer

5

Aslında varsayılanın daha az tehlikeli bir seçenek olması gerektiğini düşünüyorum. --Dev'i varsayılan yapmak ve yanlışlıkla üretimde bir besteci yüklemesi yapmak ölümcül olabilir.

— Hector Ordonez

3

İyi bir nokta --optimize-autoloader. Ayrıca şunu da düşünün --classmap-authoritative- getcomposer.org/doc/03-cli.md adresindeki belgelerden şunu görebilirsiniz: "Sınıfları yalnızca sınıf haritasından otomatik yükle. - Sınıfları biliyorsanız, kullanabileceğiniz --optimize-autoloader" ı dolaylı olarak etkinleştirir. sınıfları dinamik olarak oluşturmazsanız, muhtemelen ürün ortamınızda olması gerekir.

— Xavi Montero

6

Büyük cevap, ben optimize-autoloaderdoğrudan eklemeyi öneririm composer.json:{"config": { "optimize-autoloader": true } }

— Yvan

79

Aslında, üretim sunucusuna bağımlılıkları TEKRAR yüklemeyi şiddetle tavsiye ederim.

Benim tavsiyem, bir dağıtım makinesindeki kodu kontrol etmek, gerektiğinde bağımlılıkları yüklemek (bu kod üretime giderse dev bağımlılıklarını YÜKLEMEZ) ve ardından tüm dosyaları hedef makineye taşımaktır.

Neden?

paylaşılan barındırmada, bir komut satırına erişemeyebilirsiniz
Yapmış olsanız bile, PHP komutlar, bellek veya ağ erişimi açısından kısıtlanmış olabilir
depo CLI araçlarının (Git, Svn) yüklenmemesi olasıdır; bu, kilit dosyanız ZIP olarak indirilmiş (belirli bir taahhütte bulunmak yerine, bu sürümü almanın başka yolu yok)
üretim makineniz daha küçük bir test sunucusuna benziyorsa (Amazon EC2 mikro örneğini düşünün), muhtemelen yürütmek için yeterli bellek bile yoktur composer install
besteci hiçbir şey kırmaya çalışmazken, kısmen kırık bir üretim web sitesi ile bitirmek hakkında ne hissediyorsunuz, çünkü Besteciler kurulum aşamasında bazı rastgele bağımlılıklar yüklenemedi

Uzun lafın kısası: Composer'ı kontrol edebileceğiniz bir ortamda kullanın. Geliştirme makineniz yeterlidir çünkü Composer'ı çalıştırmak için gereken her şeye zaten sahipsiniz.

-Dev bağımlılıklarını yüklemeden bunu dağıtmanın doğru yolu nedir?

Kullanılacak komut

composer install --no-dev

Bu, üretim sunucusunun kendisi veya bir dağıtım makinesi veya herhangi bir ortamda, herhangi bir geliştirme gereksiniminin gerçek yazılım için yanlış kullanılıp kullanılmadığını bulmak için son bir kontrol yapması gereken geliştirme makinesinde çalışır.

Komut, composer.lock dosyasında bildirilen geliştirici gereksinimlerini yüklemez veya etkin olarak kaldırmaz.

Geliştirme yazılımı bileşenlerini bir üretim sunucusuna dağıtmanın sakıncası yoksa, çalışan composer installaynı işi yapar, ancak hareket ettirilen bayt miktarını artırır ve daha büyük bir otomatik yükleyici bildirimi oluşturur.

— Sven
kaynak

14

İlginç bir iş akışı, ancak büyük bir con var : Depolar asla satıcı klasörünü / içeriğini (Composer sayfasındaki resmi ifadeler) asla içermemelidir, bu nedenle doğrudan git tabanlı bir dağıtımda (ortak bir standart afaik, Yanlışsam düzelt). Yani temelde yukarıdaki çözüm sadece "eski okul" FTP dağıtım ile çalışır!? Lütfen bunu daha ayrıntılı

— tartışalım

17

Önerilen iş akışım, kodu GIT aracılığıyla üretim sunucusuna aktarmayı içermiyor. Aslında, tavsiye etmem, çünkü bunu yapmak sizi üretim sunucusuna Composer bağımlılıklarını yüklemeye zorlayacaktır, bu da herhangi bir sayıda sorunu ortaya çıkarabilir. Dağıtımınızın sorunsuz bir şekilde çalışmasını istiyorsanız, geçerli sürümü yok edip değiştirmeden önce uygulamayı çalıştırmak için gereken tüm kodu bir araya getirmeniz gerekir. FTP'yi sevmiyor musunuz? SSH üzerinden RSync yapın, ardından bir symlink'i çevirerek sürümleri değiştirin. Ama isterseniz prod içine itme, ödeme ve besteci yükleme yapabilirsiniz.

— Sven

2

@Panique: Yorumunuzun bir kısmını gördüm ve cevaplamak zorundayım: "git tabanlı bir dağıtımda üretime itildi (bu ortak bir standart afaik, yanlışsam beni düzelt)" - Hayır, bu ortak bir standart değildir. Bunu yapmanın sadece bir yolu var.

— Sven

1

Çalıştığım ekip bunu iş akışına büyük bir başarıyla dahil etti. Bir derleme makinemiz var (Jenkins, elbette): 1) SC 2'den kontroller) besteci yükleme / güncelleme 3) birim testleri çalıştırır 4) dev bağımlılıklarını kaldırır 5) bir phar dosyası ( app-1.34.pharvb. ) Oluşturur . Bu dosyanın ne zaman alınacağına, nereye aktarılacağına ve sonra ne yapılacağına karar veren ayrı bir mekanizma var. Bazı ekipler, sunucuya girdikten ve bazı ekipleri olduğu gibi çalıştırdıktan sonra phar'ı paketinden çıkarmayı seçer. Dağıtımlarımızın istikrar ve tekrarlanabilirliğine çok güven verdi.

— Josh Johnson

3

Bu cevaba% 100 katılıyorum. Composer dağıtım sunucusuna veya git'e yüklenmemelidir. Sürekli Dağıtım / Entegrasyon sunucularının getirme kaynağı ve bağımlılıklarını tam olarak yönetmesi gerekir: git pull> composer install> deploy

— Eric MORAND

4

Şimdi require-devvarsayılan olarak etkindir, yerel kalkınma için yapabileceğiniz composer installve composer updateolmadan--dev seçenek .

Üretime dağıtmak istediğinizde composer.lock, gelen hiçbir paketin olmadığından emin olmanız gerekir.require-dev .

Bunu ile yapabilirsiniz

composer update --no-dev

Yerel olarak test ettikten sonra --no-dev, her şeye göre üretim ve kurulum için dağıtım yapabilirsiniz composer.lock. --no-devBurada tekrar seçeneğe ihtiyacınız var, aksi takdirde besteci "Kilit dosyası zorunlu yazılım bilgisi içermiyor" diyecektir .

composer install --no-dev

Not: Geliştirme ve prodüksiyon arasında fark yaratma potansiyeline sahip herhangi bir şeye dikkat edin! Genellikle dev araçlarını dahil etmek büyük bir ek yük olmadığından, mümkün olan her yerde gereksinimden kaçınmaya çalışırım.

— dave1010
kaynak

1

Bu aslında ayrıntılarda yanlıştır. composer.lockGeliştirici bağımlılıklarını kontrol etmeye gerek yoktur . Basitçe çalışacaksınız composer install --no-devve yalnızca düzenli bağımlılıkları yükleyeceksiniz - aslında, Composer bu adımdaki geliştirici bağımlılıkları da kaldıracak.

— Sven

Benim yerel Eğer composer.lockvardı dev onun içinde bağımlılıklar (potansiyel ve non-dev paketleri sürümlerini etkilenen) daha sonra bunu üretimde olacağını nasıl yansıtacak şekilde güncellemek isterdim. Bu aynı zamanda hata composer install --no-devgibi üretimde çalışmaya zorlar composer install. Teknik olarak haklı olduğunu düşünüyorum; bu gerekli değildir, ancak sevdiğim ekstra bir güvenlik seviyesidir.

— dave1010

Tamam, demo senaryo: Uygulamanız dev/toolve gerektirir prod/lib:~1.0. En yeni prod / lib 1.3'tür, ancak dev / tool da gerektirir prod/lib:1.1.*. Sonuç: 1.1.9 sürümünü (1.1.x dalının en yenisi) yükleyecek ve geliştirme sırasında kullanacaksınız. Ben sadece güncellemek güvenli DEĞİL söyleyebilirim --no-dev, bu nedenle en yeni prod / lib 1.3 dahil ve her şeyi test etmeden çalışır varsayalım. Ve belki de dev / tool eksikliğinden dolayı test yapmak imkansızdır. Üretimde dev / araca ihtiyaç duyulmadığı için piyasaya sürülmemesi gerektiğini, ancak yazılımın prod / lib 1.1.9 kullanması gerektiğini varsayabilirim.

— Sven

Eğer kullanıyorsanız --no-dev, cevapta bahsettiğim gibi, yerel olarak test etmeniz gerekir. Yine de hiç kullanmamanızı tavsiye ederim --no-dev.

— dave1010

Yani temelde bunu öneriyorsunuz: composer updatesonra biraz geliştirme yapın, sonra yapın composer update --no-dev, sonra serbest bırakma testini yapın, sonra üretime itin ve yapın composer install --no-dev. İki sorun: 1. Dev bağımlılıkları olmadan sürümü test edemiyorum ve 2. Üretimde Git ile kurulum yapamıyorum.

— Sven

3

Üretim sunucularda ben adlandırmak vendoriçinvendor-<datetime> ve dağıtım sırasında iki satıcı dizinleri olacaktır.

Bir HTTP çerezi sistemimin yeni satıcıyı seçmesine neden oluyor autoload.php ve test ettikten sonra, gelecekteki tüm istekler için eski satıcı dizinini devre dışı bırakmak için aralarında tamamen atomik / anlık bir anahtar yapıyorum, sonra birkaç gün sonra önceki dizini silerim.

Bu, apache / php içinde kullandığım dosya sistemi önbelleklerinden kaynaklanan herhangi bir sorunu önler ve ayrıca herhangi bir etkin PHP kodunun önceki satıcı dizinini kullanmaya devam etmesine izin verir.

Buna karşı tavsiye edilen diğer cevaplara rağmen ben şahsen koşuyorum composer install olarak sunucuda çalışıyorum, çünkü bu benim evreleme alanımdan (dizüstü bilgisayarımdaki bir VM) rsync'den daha hızlı.

Ben kullanıyorum --no-dev --no-scripts --optimize-autoloader. Ortamınıza uygun olup olmadığını kontrol etmek için her biri için dokümanları okumalısınız.

— Abhi Beckert
kaynak

2

Süreci otomatikleştirmek daha iyi olduğunu düşünüyorum:

Git deponuza composer.lock dosyasını ekleyin, bıraktığınızda composer.phar install --no-dev kullandığınızdan emin olun , ancak dev makinenizde endişeniz olmadan herhangi bir besteci komutunu kullanabilirsiniz, bu üretime gitmeyecek, üretim bağımlılıklarını kilit dosyasına dayandıracaktır.

Sunucuda bu belirli sürümü veya etiketi satın alırsınız ve uygulamayı değiştirmeden önce tüm testleri çalıştırırsınız, testler geçerse konuşlandırmaya devam edersiniz.

Test geliştirici bağımlılıklarına bağlıysa, bestecinin test kapsamı bağımlılığı olmadığından, testi dev bağımlılıklarla ( composer.phar install ) çalıştırmak için çok şık olmayan bir çözüm çalıştırılabilir , satıcı kitaplığını kaldırın, çalıştırın - -no-dev tekrar, bu önbellek bağımlılıkları kullanır, bu yüzden daha hızlı. Ancak, diğer oluşturma araçlarındaki kapsam kavramını biliyorsanız bu bir hack'tir.

Bunu otomatikleştir ve gerisini unut, bira iç :-)

Not: @Sven yorumunda olduğu gibi, composer.lock dosyasını kontrol etmemek iyi bir fikir değildir, çünkü bu besteci kurulumunun besteci güncellemesi olarak çalışmasını sağlayacaktır.

Bu otomasyonu http://deployer.org/ ile yapabilirsiniz basit bir araçtır.

— Giovanni Silva
kaynak

2

İşlemekle ve kontrol Değil composer.lockyapacak composer installgibi davranıp composer update. Yani konuşlandırdığınız sürümler geliştirdiğiniz sürümler değil. Bu, muhtemelen sorun yaratacaktır (ve dahası, Composer'da "değiştir" ile yakın zamanda çözülen tek güvenlik sorununun ışığında). composer updateHiçbir şey kırılmadığını doğrulamadan ASLA katılımsız çalışmamalısınız.

— Sven

1

@ Bu, aynı yorumda konuşlandırılmadan önce Birim testlerini otomatik olarak çalıştırmak için bir öneridir. Ama haklısın, composer.lock dosyasını yine de saklaman daha iyi.

— Giovanni Silva

Şimdi açıklamanız gereken tek şey: PHPUnit gibi dev bağımlılıkları olmadan testleri sunucuda nasıl çalıştırıyorsunuz?

— Sven

Bağımlılıklar, testler ve dağıtım, Java Gradle veya SBT veya Maven gibi bir araca yerleştirildiyse çok iyi olurdu (maven çok iyi değil). Besteci phpunit ve dağıtım birlikte çalışmasını sağlayan bir PHP aracı. Ya da bu şeyleri yapmak için bir Gradle veya Scala SBT eklentisi, agnostik oluşturma araçları oldukları için, eklenti, javascript'i en aza indirmek ve sass derlemek, css'yi en aza indirmek gibi varlıklarla bile çalışabilir. Birisi bir şey biliyor mu?

— Giovanni Silva

1

Tabii ki bu gerçek ortamı test etmek için sunucuda yapılır, ancak site hayaletinde doğrudan değil, bunu ayrı bir geçici klasörde yapabilir ve başarılı olduğunda sonucu vhost'a taşıyabilirsiniz

— Giovanni Silva