Paylaşılan proje kodu kullanarak php web uygulamaları geliştirme ve dağıtım işlemek için Öneriler

2 Cevap php

Ben (yalnız bir geliştirici için) en iyi yolu nedir merak ediyorum

  1. diğer projelerin koduna bağlıdır bir proje geliştirmek
  2. sunucuya çıkan proje dağıtmak

Ben svn kodumu koymak planlıyorum, ve ayrı bir proje olarak kodunu paylaştı. Ben tam olarak tahmin edemez formaliteler: svn ile ilgili sorunlar vardır.

Ben okudum

ama özel bir şey php projeleri (ve diğer yorumlanır kaynak kodu) ile vardır: kitaplıklarınızdaki kaynaklanan hiçbir nihai yürütülebilir yoktur. Dış bağımlılıklar ham kaynak kodu dolayısıyla her zaman vardır.

İdeal gerçekten geliştirmek mümkün olmak istiyorum simultaneously on one project and the projects it dependends on.

Possible way: Check out a projects' dependency in a sub folder as a working copy of the trunk. Problems I foresee:

  1. Bir proje dağıtmak istediğinizde, doğru, kendi bağımlılıkları dondurmak isteyebilirsiniz?

  2. Bağımlılık kod projeler deposunda bir nüsha olarak sona olmamalıdır bence.

    * (Update1: Ben ayrıca svn varsayalım: Geri sembolik düşemez eğer görmezden bakın my comment, sorun teşkil edecektir)

    Hala kullanımı birleşim noktaları gerekmez önerileri arıyorum. Onlar bazı programlar kesilebilir, hangi winxp desteklenmeyen hack bir tür olan *

This leads me to the last part of the question (as one has influence on the other): how do you deploy apps whith such dependencies? I've looked into BuildOut for Python, but it seems to be tightly related to the python ecosystem (resolving and fetching python modules from the web etc).

Ben senin en iyi uygulamalar hakkında bilgi edinmek için çok istekli.

2 Cevap

Bir yaklaşım olabilir:

  • bağımlılık başına bir depo
  • bağımlılıkları ve sürümlerini (bağımlılıkları muhtemelen hatta kendi versiyonları) belgelemektedir projeniz için bir ihtiyaç yapılandırma dosyası
  • geliştirme, test ve dağıtım ortamlarının kurulumu işlemek otomasyon komut (kez kurulum prosedürünü belgeleyen ve yapılandırılabilir ve çalıştırılabilir yapmak kadar basit olabilir)

Bunun birçok faydası vardır:

  • kolayca (hatta otomatik olarak) sizin bağımlılıkları (başka daha iyi bir kütüphane mevcuttur) eskimiş veya güvenlik açıklarını bilinen olmadığını kontrol edebilirsiniz.
  • bağımlılıkları hakkında daha fazla farkındalık
  • kolay bağımlılıkları nedeniyle hata ayıklama / fix / patch sorunları
  • svn görmezden: Eğer gelecekte Git, BZR, Hg gibi dağıtılmış sürüm kontrolü geçtiğinizde formaliteler de ağrıyı hafifletmek olabilir.
  • Eğer başka bir makinede (veya sonunda başka bir geliştirici devraldı veya birleştirir) üzerinde ortamı kurmak istiyorsanız bu size zaman ton tasarruf edecek

Web-geliştirme ve sunucu yönetiminde popüler olan bazı KISS otomasyon araçları:

Özet:

Gereksinimleri (tercihen makine tarafından okunabilir -> yaml, ini, json, xml) belge ve proje dışında bağımlılıkları anlaştım. Bu otomatik kurulum ve dağıtım daha kolay ve versiyon kontrol sistemi (kaygıları, iş için en iyi araç, vb ayrılması) daha az bağımlı hale yönlendirme biraz sağlar.

Bu ucuz gelebilir ama ben bu soruları parçacığı sizin için bir cevap olduğunu düşünüyorum: http://stackoverflow.com/questions/3771373/svn-folder-structure-organization/3777709#3777709

Belirtildiği gibi zararlı olarak formaliteler: Sürece kendi depo içinde kalmak gibi svn düşünün olmaz. Sadece aşırıya kaçmayın.

Bu strateji ile dağıtım TÜM (koşmak ödeme, kâr) bir etiketi olduğu için de pasta bir parçasıdır. Senin dizin yapısı tüm katmanları, şube, etiketleri, gövde üzerinde aynı kalır.

Etiketleri Externals yönlendiren (ve svn sunucu üzerinde etiketleri salt okunur yaparak) tarafından size beklediğiniz kütüphane almak% 100 emin olabilirsiniz.

etiketler