conflitti Evita in script di installazione con più sviluppatori

Question

Stiamo usando Magento script di installazione che si trovano nei SQL e dati directory per propagare le modifiche dei dati a tutte le copie di lavoro e ambienti. Questo include le impostazioni di configurazione, la creazione di nuove tabelle, attributi e così via.

[Aggiornamento] Codice progetto specifico va in più Client_Module le estensioni.

Tuttavia abbastanza spesso abbiamo bisogno di aggiungere migrazioni di dati (cioè script di installazione) che non possono essere attribuiti ad un interno esistente. Così usiamo un Company_Client modulo (o Client_General, someting del genere) per questi cambiamenti.

Imagine più sviluppatori a lavorare sullo stesso progetto, allo stesso tempo. Può accadere che gli sviluppatori A e B sono entrambi sviluppatore urtando il numero di versione di Company_Client e creare un nuovo script di aggiornamento. Anche se si aggiorna il lavoro copia di frequente, si otterrà conflitti più spesso di quanto si vuole, devono cambiare la versione del proprio interno Company_Client locale e fare in modo che gli script dei vostri colleghi corrono quando si recupera i loro cambiamenti.

Tre soluzioni dalla parte superiore della mia testa:

1. Creare molte estensioni per le parti del progetto-specifiche (inquina la piscine di codice con molte estensioni non necessarie).
2. Creare un'estensione per sviluppatore per script di aggiornamento (può funzionare, ma non ha senso).
3. stringere i denti e fare manualmente questo tipo di conflitto resultion ho spiegato prima.

Come si fa a gestire questo?

Answer 1

Credo di aver trovato una soluzione che soddisfa le mie esigenze.

Il mio prerequisiti :

• Utilizzare una sola estensione per tutte le piccole migrazioni di dati / struttura che non rientrano in alcuna altra estensione
• Abilita a più sviluppatori di creare script di installazione senza dover conflitti a causa dei numeri di versione

La prima parte per la mia soluzione: utilizzare più risorse script di installazione all'interno di un'estensione. Questo è facilmente possibile (contenuto di config.xml):

<?xml version="1.0"?>
<config>
    <!-- Your other config stuff... ->
    <global>
        <!-- Your other config stuff... ->
        <resources>
            <[your_setup_name_1]>
                <setup>
                    <module>[Your_Extension]</module>
                </setup>
            </[your_setup_name_1]>
            <[your_setup_name_2]>
                <setup>
                    <module>[Your_Extension]</module>
                </setup>
            </[your_setup_name_2]>
        </resources>
    </global>
</config>

Il problema si dovrà affrontare è che tutte le risorse di configurazione avrà lo stesso numero di versione nel core_resource tabella del database (che è il numero di versione specificato nel nodo modules). Se non si desidera che in quanto creerà problemi e conflitti per gli sviluppatori di nuovo.

Inserire la seconda parte della mia soluzione: un risorsa personalizzata classe di installazione con un piccolo cambiamento. Modificando una riga in ciascuno dei metodi applyDataUpdates() e applyUpdates() si può dire Magento per leggere il numero di versione di un altro nodo XML.

Sostituire

$configVer = (string)$this->_moduleConfig->version;

con

$configVer = (string)$this->_resourceConfig->setup->version;

Ora è possibile specificare diversi numeri di versione per ciascuna delle vostre risorse di configurazione:

<?xml version="1.0"?>
<config>
    <!-- Your other config stuff... ->
    <global>
        <!-- Your other config stuff... ->
        <resources>
            <[your_setup_name_1]>
                <setup>
                    <module>[Your_Extension]</module>
                    <class>Emzee_MultipleSetupVersions_Model_Resource_Setup</class>
                    <version>0.0.3</version>
                </setup>
            </[your_setup_name_1]>
            <[your_setup_name_2]>
                <setup>
                    <module>[Your_Extension]</module>
                    <class>Emzee_MultipleSetupVersions_Model_Resource_Setup</class>
                    <version>0.0.2</version>
                </setup>
            </[your_setup_name_2]>
        </resources>
    </global>
</config>

Gli script di installazione verrà eseguito in modo indipendente e il numero di versione corrispondente verrà scritto core_resource. Tutto il resto dovrebbe funzionare come sempre.

Ora non resta che decidere la vostra strategia come dividere le risorse (una risorsa messa a punto per entità, per sviluppatore, ...).

È possibile dare un'occhiata a una prova di estensione concetto su Github .

Answer 2

Dalla convenzione di cui sopra Company_Client denominazione suona come si lascia solo spazio per 1 modulo specifico progetto per client che sta costringendo a più sviluppatori di lavoro all'interno dello stesso modulo, mentre probabile lo sviluppo di caratteristiche completamente diverse.

Perché non andare con una configurazione in cui Client_Module modulo descrive lo scopo del modulo in fase di creazione? Questo approccio ha funzionato bene per me in passato e assicura anche che non sta sviluppando un singolo modulo, piuttosto gonfio che fa un sacco di cose diverse.

A volte capisco è necessario apportare piccole modifiche che non giustificano realisticamente il proprio modulo e in questo caso io non tendono ad utilizzare un modulo con lo stesso nome del modulo in tutti i clienti, ma il client ovviamente cambiando - ho optato per Client_Override per questi tipi di cambiamenti.

Si sta andando sempre di imbattersi in conflitto codice di tanto in tanto, ma far rispettare un flusso di lavoro corretto, buon modulo di denominazione e l'uso intelligente di ramificazione nel repository mantiene questo al minimo.

Answer 3

Sto sviluppando un'estensione chiamata "Mageploy" con l'intento di risolvere il problema di mantenere diversi ambienti in sincronia:

https://github.com/pug-more/mageploy

Si deve ancora essere esteso, ben documentato e testato anche se sto già usando in un paio di progetti che hanno alcuni vantaggi.

E 'open source e qualsiasi aiuto o suggerimento wil essere apprezzato.

Saluti