Controllo versione per sviluppo modulo

Mi chiedo se ci siano delle buone convenzioni, per quanto riguarda il controllo della versione, per lo sviluppo di un modulo che stai usando sia in una singola istanza di Magento sia che desideri rilasciare come modulo di comunità.

Inizialmente quello che ho tentato di fare era usare modman per gestire il modulo al di fuori del mio repository di istanze Magento principale. Ma questo ha finito per essere problematico su più livelli. Avere un unico repository che puoi facilmente installare in diversi ambienti o ripristinare in produzione è estremamente utile e direi addirittura che è diventato una parte necessaria del mio flusso di lavoro.

Quello che sto facendo attualmente è svilupparlo all'interno del mio repository del sito e sto pianificando di dividerlo presto in un repository separato. A quel punto, probabilmente farò:

• Costruisci nel mio ambiente locale all'interno di un repository di singoli moduli usando modman
• Copia le modifiche nel repository del sito quando sono pronto per distribuire il codice

Sperando che ci sia un modo migliore?

Abbiamo alcuni moduli in cui abbiamo fatto questo e quello che essenzialmente abbiamo fatto è:

• Imposta un repository Git per il modulo.
• Distribuisci questo modulo nella base di codice del sito di produzione e impegna tutto, incluso:
  • soft-link creati da modman
  • la directory .modman che ospita il repository di moduli clonato
• Usa modman per "distribuirlo" in altre versioni e / o ambiente di sviluppo per sviluppo e test.

In questo modo otterrai la flessibilità di cui hai bisogno per lo sviluppo del modulo, versioni anche del codice sul singolo sito e, se apporti modifiche al modulo nella base di codice del sito singolo, puoi impegnarle direttamente nel repository del modulo poiché il repository è presente nella directory .modman.

AGGIORNAMENTO: Quando inizialmente ho scritto questo, non sono riuscito a prendere in considerazione nella mia risposta che Git non consente a (sotto) moduli di essere impegnati in un repository, nel qual caso "commettere tutto" ha bisogno di qualche elaborazione!

Per inciso, questo è perché l'ho fatto più spesso usando modman per distribuire moduli ospitati nei repository Git in una base di codice di produzione ospitata da SVN ... e Subversion non ha scrupoli che gli impediscono di eseguire il commit dell'intero albero Git nel VCS.

Quindi ecco qui ...

1. Se stai usando SVN per ospitare il codice del sito di produzione, non dovresti avere problemi poiché Subversion non ha (praticamente) il concetto di sottomoduli. Non gli dispiacerà.

2. Se si utilizza Git per il codice del sito di produzione, sarà necessario utilizzare i sottomoduli per "eseguire il commit di tutto" nel repository di codice del sito. Dopo aver usato modman per clonare qualcosa del genere:

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

   Ti consigliamo anche di aggiungerlo come un sottomodulo in questo modo:

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

   Una volta fatto questo, dovresti essere in grado di aggiungere la directory .modman e il file .gitmodules all'indice e impegnarlo.

   Dopo aver clonato il repository che utilizza questi moduli installati tramite modman, è sufficiente avviare i sottomoduli e aggiornare:

   git submodule init
   git submodule update

PS: ora uso Git a tempo pieno su tutti i nuovi progetti, quindi spero che questa svista non accada di nuovo. Scusate ragazzi. ;)

Sembra che l'attuale convenzione fornisca supporto per:

• Compositore - http://getcomposer.org/
• Modman - https://github.com/colinmollenhour/modman
• Repository Github

Per quanto riguarda la struttura delle directory, è minimale e preferibilmente il modulo è installato nel pool di codici Community.

Una struttura di directory suggerita minima sarebbe:

.
└── 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

Opzionale / simpatico:

• Pagina di destinazione di Github con una descrizione, alcune schermate e alcune funzionalità puntate.
• Anche il collegamento a un negozio demo installato sarebbe bello
• Una panoramica / due minuti di panoramica del prodotto

Modifica: potrei aver frainteso.

L'uso di una combinazione di modman / gitignore può mantenere il modulo isolato dall'ambiente di test. Usando la struttura di cartelle sopra puoi consentire esplicitamente il commit / installazione solo dei file del tuo modulo nel tuo repository. In questo caso, la risposta di David è più applicabile. Il supporto di Modman per dev / deploy sembra essere il consenso.

Anche se non l'ho ancora provato da solo, consiglierei di usare il compositore per quello.

Controllo delle versioni comprese le dipendenze

Mantenendo il composer.lockfile nel repository, si riparano le versioni di tutti i moduli e si può sempre ripristinare una versione specifica (un ramo, un tag o una versione precedente) utilizzando VCS ( git checkout, svn ..) e quindi composer.phar install.

svantaggi

Un problema che si pone è che la tua distribuzione può facilmente dipendere da più fonti (ad esempio GitHub) creando più punti di errore.

Quindi avremmo bisogno di un qualche tipo di cache o proxy che memorizzi quei moduli in modo da essere sempre in grado di implementare.

Satis sembra essere in grado di servire questo scopo (vedi https://github.com/researchgate/broker ) e la mia domanda /programming//q/16211671/288568

Kalen,

Forse non ho capito bene il tuo flusso di lavoro, ma sembrava che tu stia sviluppando in un repository Magento localmente, per poi separarti in un repository modman. Perché non modificare semplicemente ./modman/modulesname/CONTENTS nel tuo IDE e inviare il codice al repository del modulo indipendentemente nello stesso flusso di lavoro che usi per sviluppare. puoi usare modman per la distribuzione in produzione, puoi interagire con i singoli repository nella cartella .modman / modulesname / da cli o aggiungendo una fonte di versioning al tuo IDE, anche se in realtà usi .basedir per mantenere i percorsi collegati al tuo repository fuori dai tuoi webroot giocherà meglio.

C'è anche una caratteristica davvero interessante di modman che molte persone non sembrano usare. Lo script bash interpreta un file .basedir nel repository .modman, se il file non esiste modman applica le regole di collegamento simbolico nel file modman allo stesso livello della cartella .modman ... se esiste il file .basedir, il file i contenuti descrivono una sottocartella che è il livello più alto del tuo codice Magento uno in basso rispetto al percorso .modman ... in altre parole, potresti eseguire (e lo faccio) tutte le versioni di base di Magento in cartelle come "BaseMagento1.9.1.0" 'BaseMagento1.14.2.0' e modman iniziano la cartella che li contiene. Aggiungi un file .basedir nel percorso .modman e puoi modificare facilmente i contenuti. Questo funziona bene per il test della versione.