Modül Geliştirme için Versiyon Kontrolü

Tek bir Magento örneğinde kullandığınız ve ayrıca bir topluluk modülü olarak yayınlamayı istediğiniz bir modül geliştirmek için sürüm kontrolüne kadar herhangi bir iyi kural olup olmadığını merak ediyorum.

Başlangıçta, benim yapmaya çalıştığım, ana Magento örnek havuzumun dışındaki modülü yönetmek için modman kullanmaktı. Ancak bu, çoklu seviyelerde sorunlu hale geldi. Farklı ortamlara kolayca kurabileceğiniz veya üretimde geri alabileceğiniz tek bir havuza sahip olmak son derece yararlıdır ve iş akışımın gerekli bir parçası haline geldiğini söyleyebilirim.

Şu anda yaptığım şey, onu site depomun içinde geliştirmek ve yakında bunları ayrı bir havuza bölmeyi planlıyorum. Bu noktada, muhtemelen yapacağım şey:

• Yerel ortamımda modman kullanarak ayrı bir modül havuzunda oluştur
• Kod dağıtmaya hazır olduğumda değişiklikleri site havuzuna kopyala

Umarım daha iyi bir yol var mı?

Bunu yaptığımız ve temelde yaptığımız şey:

• Modül için Git deposu kurun.
• Bu modülü üretim sahasının kod tabanına yerleştirin ve aşağıdakileri içeren her şeyi yapın:
  • modman tarafından oluşturulan yumuşak bağlantılar
  • klonlanmış modül deposunu barındıran .modman dizini
• Devman ve test için diğer sürümlere ve / veya dev ortamına "dağıtmak" için modman kullanın.

Bu şekilde yapmak size modül geliştirme için ihtiyaç duyduğunuz esnekliği sağlar, tek sitedeki kodu da sürümlendirir ve tek sitedeki kod tabanında modülde değişiklik yaparsanız, bunları doğrudan modül havuzuna geri alabilirsiniz. repo .modman dizininde var.

GÜNCELLEME: Bunu ilk yazdığımda, cevabımdaki Git'in (alt) modüllerin bir depoya taahhüt edilmesine izin vermediğini hesaba katmadım, bu durumda “her şeyi taahhüt etmek” biraz daha fazla ayrıntıya ihtiyaç duyuyor!

Bu arada, bunun nedeni, Git reposunda yer alan modülleri SVN tarafından barındırılan bir üretim kod tabanına yerleştirmek için modman kullanarak daha sık yaptığımdır. Subversion, tüm Git ağacını VCS'ye vermesini önleyen hiçbir zorluk içermez.

Yani işte gidiyor…

1. Üretim sahasının kodunu oluşturmak için SVN kullanıyorsanız, Subversion'un (pratik olarak) hiçbir alt modül kavramı olmadığı için hiçbir problem yaşamayacaksınız. Aldırmaz.

2. Git, üretim sitesinin kodu için kullanıyorsanız, sitenin kod deposuna "her şeyi yapmak" için alt modülleri kullanmanız gerekir. Bu gibi bir şey klonlamak için modman kullandıktan sonra:

   modman clone ssh://git@bitbucket.org/<user>/<repo>.git

   Ayrıca bunun gibi bir alt modül olarak eklemek isteyeceksiniz:

   git submodule add ssh://git@bitbucket.org/<user>/<repo>.git .modman/<repo>

   Bunu yaptıktan sonra, .modman dizini ve .gitmodules dosyasını dizine ekleyebilmeli ve onaylayabilmelisiniz.

   Modman aracılığıyla kurulan bu modülleri kullanan depoyu klonladıktan sonra, sadece alt modülleri yerleştirip güncelleyin:

   git submodule init
   git submodule update

PS Şimdi tüm yeni projelerde Git'i tam zamanlı olarak kullanıyorum, bu yüzden umarım bu gözetim bir daha gerçekleşmeyecek. Üzgünüm beyler. ;)

Şu anki sözleşmenin aşağıdakileri desteklemesi gerektiği görünüyor:

• Besteci - http://getcomposer.org/
• Modman - https://github.com/colinmollenhour/modman
• Github deposu

Dizin yapısına gelince, minimum düzeydedir ve tercihen modül Topluluk kodu havuzuna kurulur.

Çıplak minimum önerilen dizin yapısı şöyle olacaktır:

.
└── app
    ├── code
    │   └── community
    │       └── YourCompany
    │           └── YourModule
    │               ├── Block
    │               ├── Model
    │               │   └── Observer.php
    │               └── etc
    │                   └── config.xml
    ├── design
    │   └── frontend
    │       └── base
    │           └── default
    │               ├── layout
    │               │   └── module.xml
    │               └── template
    │                   └── yourmodule
    └── etc
        └── modules
            └── YourCompany_YourModule.xml

İsteğe bağlı / güzeller:

• Bir açıklama, bazı ekran görüntüleri ve bazı kurşun özellikleri ile Github açılış sayfası.
• Yüklü bir demo mağazasına bağlantı vermek de iyi olurdu
• Ürününüzün ekran görüntüsü / iki dakikalık görünümü

Düzenleme: Yanlış anlamış olabilirim.

Modman / gitignore birleşimini kullanmak, modülünüzü test ortamınızdan uzak tutabilir. Yukarıdaki klasör yapısını kullanarak, yalnızca modül dosyalarının depoya yüklenmesine / kurulmasına açıkça izin verebilirsiniz. Bu durumda, David'in cevabı daha geçerlidir. Dev / deploy için Modman desteği, fikir birliği gibi görünüyor.

Henüz kendim denememiş olsam bile, bunun için besteci kullanmanızı tavsiye ederim .

Bağımlılıklar dahil versiyonlama

composer.lockDosyayı depoda tutarak, tüm modüllerin sürümlerini düzeltirsiniz ve VCS'nizi ( , ) ve ardından da her zaman belirli bir sürümü (dal, etiket veya eski sürüm) geri yükleyebilirsiniz .git checkoutsvn ..composer.phar install

Dezavantajları

Ortaya çıkan bir sorun, dağıtımınızın kolayca birden fazla başarısızlık noktası yaratan birden çok kaynağa (örneğin GitHub) bağlı olmasıdır.

Bu yüzden, bu modülleri depolayan bir tür önbellek veya proxy'ye ihtiyacımız olacak ve böylece her zaman dağıtabileceğiz.

Satis bu amaca hizmet edebiliyor gibi görünüyor (bkz. Https://github.com/researchgate/broker ) ve sorumu /programming//q/16211671/288568

Kalen,

Belki de iş akışınızı tam olarak anlayamadım, ama yerel olarak magento deposunda geliştikten sonra modman deposuna ayrılıyor gibisiniz. Neden IDE'nizde ./modman/modulesname/CONTENTS dosyasını düzenlemeyin ve geliştirmek için kullandığınız aynı iş akışında bağımsız olarak kod modül modülüne bastırın. modman'ı prodüksiyonda kullanmak için kullanabilirsiniz, .modman / modulename / klasöründeki bireysel repo'yu cli'dan veya IDE'nize sürümleme kaynağı ekleyerek etkileşime sokabilirsiniz; webroot daha iyi oynayacak.

Ayrıca, pek çok insanın kullanmadığı görünen modman'ın gerçekten hoş bir özelliği var. Bash betiği, .modman deposundaki bir .basedir dosyasını yorumlar, eğer dosya mevcut değilse, modman, modman dosyasındaki symlink kurallarını .modman klasörü ile aynı düzeyde uygular ... .basedir dosyası varsa, içeriği Magento kodunuzun en üst seviyesi olan bir .modman yolundan aşağıya doğru bir alt klasörü açıklar ... başka bir deyişle, 'temelMagento1.9.1.0' gibi klasörlerdeki tüm temel Magento sürümlerini çalıştırabilir (ve yapabilirim). 'BaseMagento1.14.2.0' ve modman bunları içeren klasörü başlatır. .Modman yoluna bir .basedir dosyası ekleyin; içeriği kolayca değiştirebilirsiniz. Bu sürüm testi için iyi çalışıyor.