<small>Aggiornato il 2 maggio 2019</small>

 consentono di tenere traccia delle modifiche fatte nel tempo e di collaborare più efficacemente all’interno di team composti da molte persone in particolare se, come in Bitbull, lavorano da remoto.

Non ci addentreremo nella spiegazione di che cos’è un sistema di controllo di versione, ma bensì vedremo come gestire al meglio il flusso di sviluppo con Git, il software di controllo versione distribuito.

Normalmente un repository è suddiviso in due branch, master e develop, dove master è il principale branch in cui risiede il codice della versione del progetto in produzione mentre develop è la versione con gli ultimi sviluppi che stanno per essere pubblicati ed è il branch normalmente attivo in ambiente di test (in seguito staging). Ogni modifica/aggiunta si fa su un feature branch generato da develop. Mentre gli hotfix, si fanno direttamente su master (e poi si allinea develop).

Vedremo come fare questo usando Git Flow che non è altro che una procedura per renderlo automatico ma con alcune cose in più e delle regole per farlo correttamente.

Prima di utilizzare git flow, si creavano dei branch da develop chiamati ad esempio "fix123" e la struttura visiva del repo risultava così:

In Bitbull, i feature branch eravamo soliti chiamarli già così: "feature/fix123" per cui la struttura visiva (e qui possono capire di più quelli che usano 

- develop
 |_ feature
   |_fix123
 - master

Dopo aver imparato git flow ho capito perché.

Ogni progetto/repo pubblico o privato dovrebbe avere un 

 per ogni versione che viene rilasciata nella forma x.y.z in modo tale da poter far riferimento a questo numero di versione ed essere in grado di "viaggiare nel tempo" tra una versione e l'altra a seconda di cosa ognuna contiene piuttosto che doversi ricordare un commit specifico. E per sapere cosa ogni versione contiene ce lo dice il release note o changelog (discusso in seguito).

Il numero di versione si costruisce usando il 

MAJOR serve ad indicare una versione non retrocompatibile con la precedente (una rottura con il passato, 

MINOR è invece una modifica retrocompatibile (quindi una 

PATCH correzione di bug retrocompatibili (quindi un 

Per aiutarci potremo tenere a mente la terna:

Si intendono feature tutti quei task che prevedono aggiunta di funzionalità, normale svolgimento dei compiti, ecc; come hotfix, fix di bug urgenti che devono andare subito in produzione. Un fix può essere anche semplicemente l'aggiornamento di documentazione, commenti o riformattazione di codice, persino un refactoring che, per definizione, non altera il comportamento quindi non aggiunge alcuna nuova feature.

Capito questo è anche facile comprendere come per le feature serva una release mentre per gli hotfix no perché appunto vengono rilasciati direttamente in produzione senza passare dal via.

Per prima cosa va preparato il repo all'uso di git Flow.

Per chi usa SourceTree basta schiacciare un pulsante, per tutti gli altri: 

http://danielkummer.github.io/git-flow-cheatsheet/index.it_IT.html

Su SourceTree cliccate sul pulsante Git Flow

Questo comando stabilisce le nomenclature da usare in git flow che di solito sono così:

Tag version: qui si può lasciar vuoto oppure a qualcuno piace mettere "v" così che il tag di ogni versione avrà quest’aspetto: "v1.0.0"

Queste configurazioni le ritrovate nel file config situato nella cartella .git del progetto:

[gitflow "branch"]
  master = master
  develop = develop
[gitflow "prefix"]
  feature = feature/
  release = release/
  hotfix = hotfix/
  versiontag = v
  support = support/

quindi se serve modificare si può fare da qui (per coloro che usano il terminale un elenco di comandi da usare per aggiornare le config è disponibile su 

https://github.com/petervanderdoes/gitflow-avh/wiki/Reference:-git-flow-config

Fatto ciò, se siamo partiti con un solo branch, ovvero master, verrà creato develop.

Siamo ora pronti ad usare il flow. La struttura del nostro repo diventa così:

Abbiamo dei nuovi task da fare sul progetto, cambiare un colore, migliorare una pagina, aggiungere una nuova funzione ad un modulo, lavoriamo quindi ad una feature che chiameremo "TASK":

(in SourceTree pulsante gitflow > Start a new feature)

Il nuovo branch partirà automaticamente dall'ultimo commit di develop (è comunque possibile specificare un commit o una working copy revision dal quale deve partire), ci chiederà il nome del branch in cui scriviamo "TASK" e voilà ecco la nostra alberatura:

Lavoriamo pertanto su questo branch, lo facciamo vedere al cliente, gli piace, ce lo conferma e siamo pronti a portarlo in develop:

Se non vuoi sporcare la storia con commit non semantici come "merge branch feature/foo into develop" puoi utilizzare rebase unitamente allo squash.

Ma tieni conto che questo prevede che il branch sia fatto con una certa logica

. E ancora prima prevede che si abbia una certa dimestichezza con rebase e squash e capacità nel risolvere eventuali conflitti. Se così non fosse, limitati ad un 

Se però intendi procedere con rebase e squash, prima di chiuderlo assicurati che l'ultimo branch descriva in modo semantico la feature che stai andando a chiudere (es. che non sia un messaggio generico come "fix") come spiegato nel precedente paragrafo. Sconsiglio il rebase quando la storia di develop rispetto a quella del branch è nel frattempo andata di molto avanti, perché potresti andare incontro ad un'infinità di conflitti che git flow da solo non può risolvere e serve un intervento manuale. Inutile dire che è un oneroso (e talvolta inutile) dispendio di tempo.

Ecco il comando rivisto con le opzioni appena spiegate:

, riporta tutti i commit su develop di modo che la storia del repo sia aggiornata e non ci siano come detto dei brutti e insignificanti "

, equivale a sintetizzare tutti i commit della feature in uno solo (ricorda: git utilizza il messaggio dell'ultimo commit fatto sul feature branch – motivo per il quale quest'ultimo dovrebbe spiegare cosa è stato fatto in questo branch).

Chiusa la feature, il branch viene riportato su develop e viene cancellato solo dalla macchina locale. Da repository in remoto va fatto a mano o come dicono qua 

http://stackoverflow.com/questions/11151623/does-git-flow-deletes-branch-on-remote-server

Facciamo finta che questo branch basti e avanzi e lo si vuole ora portare in produzione. Occorre fare una release. Supponiamo che siamo alla versione 1.0.0 e dobbiamo rilasciare questa nuova feature:

Ecco che creiamo la release incrementando di 1 il secondo numero e 

In questo frangente, andiamo a modificare (se non presente lo andiamo a creare) la release note che può essere sotto forma di releasenote.txt o CHANGELOG.md nella root del repo. Questo file ha più o meno queste fattezze:

Nel quale vengono cioè riportate in punto elenco le modifiche fatte (si usa il markdown come markup) per cui ora qui va aggiunto un elenco di cose che questa release comprende. Siccome noi abbiamo fatto le modifiche che chiedeva il TASK scriveremo questo:

# Change Log

## 1.1.0
 - Ref. #xxxx Ho fatto il TASK

## 1.0.0
 - Version 1

Si elencano le modifiche fatte (per convenzione in Bitbull si usa aggiungere anche una referenza al task) e si fa il commit.

FATTO. La release è pronta. Prima di chiuderla è buona norma fare un giro su tutto il sito e verificare che funzioni e non si sia rotto niente. Se è tutto ok possiamo chiudere la release:

Si spunta sempre delete branch perché non è necessario mantenere questo branch (oltretutto teoricamente è un'operazione che fa una persona sulla macchina in locale aprendo e chiudendo quindi non viene nemmeno fatto il push) e si scrive il commento del tag (non è particolarmente rilevante, reperibile soltanto in 

, come convenzione mettiamo "close release").

La chiusura della release fa queste operazioni:

Facciamo push di tutto (develop e master) sul repo online:

Se si va a guardare il repo su bitbucket (o direttamente in SourceTree) si vedrà che nel branch master c'è un bellissimo tag con il nome della nuova versione:

Oh no, abbiamo appena deployato il tutto su produzione ma è uscito un bug da fissare subito. Dobbiamo perciò fare un hotfix al volo!

Il bug da fissare riguarda questa release appena lasciata per cui si incrementa l'ultimo numero della versione (che è quello appunto destinato ai bug fix)

Come si vede anche dall'immagine, il branch dell'hotfix partirà automaticamente da master senza possibilità di scelta, qui a differenza della feature, SourceTree vi chiede non il nome ma il numero della versione. Per non sbagliarsi e sapere quale usare basta guardare qual è l'ultimo numero presente nella release note / changelog e incrementare l'ultimo numero.

Eseguiamo le modifiche, ci assicuriamo che funzioni tutto e aggiorniamo la release note:

# Change Log

## 1.1.1
 - Ref. #xxxx Fixato il bug

## 1.1.0
 - Ref. #xxxx Ho fatto il TASK

## 1.0.0
 - Version 1

si esegue il commit e si chiude l'hotfix:

La chiusura dell'hotfix fa queste operazioni:

Notare che in questo caso non serve fare una release perché la modifica viene già riportata su master e develop alla chiusura del branch.

Bello. Ora abbiamo questa nuova versione di cui si può fare facilmente pull (ad esempio per aggiornare staging dopo il deploy):

La stessa cosa si poteva fare eseguendo il pull di develop, ma l’utilità dei tag si ha nei casi in cui il cliente ci dice "no aspetta non siamo pronti, ci mancano i seguenti prodotti e non possiamo ancora andare online con queste feature". A quel punto allora si ritorna alla versione di prima come se non fosse successo niente con:

Git Flow: come funziona aka Back to the future

Git Flow: how it works

E’ noto che la ricerca di base presente su Magento non è per nulla efficiente, poiché non restituisce i risultati attesi sia dal punto di vista dei termini trovati che del loro ordine in termini di rilevanza.

Il campo di ricerca è preferito rispetto alla navigazione per categorie, di conseguenza il corretto funzionamento di questo strumento diventa un fattore strategico per un e-commerce. Per questo motivo la sua ottimizzazione è un problema che presto o tardi ci verrà sottoposto.

In passato per ovviare a questo problema nei vari progetti abbiamo utilizzato server predisposti con 

/ElasticSearch oppure abbiamo acquistato dei moduli a pagamento come quello di 

Tuttavia il primo approccio per quanto performante non è immediato nella configurazione e personalizzazione mentre il secondo, per quanto un modulo possa essere ricco di opzioni, non riesce a coprire tutte le casistiche.

Se anche voi avete avuto esperienze analoghe e state cercando qualcosa di più convincente forse siete nel posto giusto.

 di integrazione di Magento che nel momento in cui scrivo è alla versione 1.6.1.

L’impatto iniziale è proprio quello di un modulo 

, probabilmente se avete effettuato delle personalizzazioni al campo ricerca rispetto al tema di default dovrete sistemarlo un po’ graficamente, tuttavia in questo senso, la presenza di un selettore DOM per stabilire dove far comparire i risultati nel layout di categoria  rende molto versatile il suo utilizzo nei vari progetti.

A livello di performance, utilizzando le API si sposta il problema dell’indicizzazione da un’altra parte almeno parzialmente, infatti nonostante sia possibile, se si ha un catalogo di 5000 o più prodotti, sconsiglio di indicizzare direttamente l’indice predisposto dal modulo che si occupa della sincronizzazione con Algolia. Utilizzate invece il sistema di 

 che fornisce il modulo stesso. Per la stessa ragione omettete questi indici da procedure di integrazione che prevedono alla fine un 

, pena il fatto che le stesse potrebbero impiegare diverse ore per terminare.

Il livello di personalizzazione è buono, si può decidere dal modulo che attributi oltre a quelli standard indicizzare e dal pannello di Algolia decidere le priorità tra di essi.

Non si può attribuirne il peso come avveniva per il modulo di Activo e nemmeno la granularità di precisione sui termini simili, tuttavia è un difetto che viene poco sentito, in quanto l’autocompletamento è davvero ben fatto: non si limita a proporre le parole che contengono il termine che stiamo digitando ma fornisce direttamente i relativi prodotti, categorie e e pagine così ci si accorge subito se c’è qualcosa di sbagliato piuttosto che di analogo al termine che si sta cercando.

Una menzione speciale al fatto che il modulo indicizza anche le categorie e le pagine; questo è un valore aggiunto non indifferente per e-commerce che ha un albero di categorie molto profondo.

Fino a qui sono certo di avervi almeno convinto a dargli una possibilità, tuttavia ci sono anche alcune note dolenti, cominciando dal prezzo.

Per utilizzare Algolia si hanno a disposizione 4 piani mensili, di cui il primo è gratuito a patto di lasciare visibile il logo di Algolia nelle ricerche e comunque è sufficiente solo per cataloghi con un massimo di 10.000 record, utile quindi solo ad e-commerce con un catalogo non troppo ampio.

E’ presente una configurazione del modulo con cui disabilitare la comparsa il logo di Algolia nei risultati dell’autocompletamento per i piani non gratuiti, se non lo si volesse rendere visibile.

Quello più economico è 59 USD al mese (o 49 USD al mese se si fa l’abbonamento annuale) tra quelli 

, e comprende il supporto clienti con tanto di consigli di implementazione e tuning per

migliorare la rilevanza dei propri risultati. Tuttavia e non è detto che tutti i clienti siano ben disposti alla spesa periodica per questa funzionalità.

Infine un paio di consigli: utilizzate una API KEY per ambiente (anche la vostra macchina di sviluppo) per evitare che sincronizzi indici di altri ambienti; Algolia è predisposto a questo nella sezione API KEY.

Impostate inoltre che le immagini visibili nella preview siano la small image dei prodotti, di default è la base image che sembra non funzionare correttamente.

E voi l’avete provato? avete qualche alternativa che sia allo stesso tempo perfomante e plug & play? Scrivetecelo nei commenti!

Ho aggiunto le informazioni aggiornate sul pricing segnalatomi da Gianluca nei commenti

Algolia su Magento

In Bitbull, quando partiamo con lo sviluppo di un nuovo progetto, per prima cosa ragioniamo su come “fare a pezzi” il progetto stesso, ovvero identifichiamo i componenti software che è necessario integrare per dare vita all’applicazione.

Il vantaggio principale che offre questo approccio è il 

, facilmente reperibile da repository pubblici, testato e manutenuto dalla community di sviluppatori, oppure da repository privati. La conseguenza è una 

pacchettizzare e rendere disponibili anche i propri moduli

, seguendo uno standard condiviso. Inoltre risulta agevole l’

aggiornamento dei singoli componenti a nuove versioni.

Nel mondo PHP il concetto di “aggregazione di componenti di codice riutilizzabili e disponibili su repository” non è recente: in passato era molto in voga l’utilizzo di PEAR che è un sistema di distribuzione di librerie PHP open-source, raccolte in un repository ufficiale quasi considerato un framework.

La principale differenza pratica tra PEAR e Composer è che il primo viene configurato globalmente sulla macchina in cui è installato e quindi le stesse librerie sono disponibili per tutti i progetti (con evidenti esplosioni di euforia degli sviluppatori che si trovano a gestire i conflitti di versione tra progetti diversi), mentre il secondo prevede sia delle configurazioni globali a livello di macchina, sia configurazioni locali di progetto.

Inoltre PEAR è decisamento obsoleto, come indicato già due anni fa da <a href="http://fabien.potencier.org/the-rise-of-composer-and-the-fall-of-pear.html" target="_blank">Fabien Potencier nel suo blog</a>.

Scegliamo un tool in base alla flessibilità e alla propensione al rinnovamento e quindi, ad oggi, ci focalizziamo su Composer!

: consente di dichiarare la lista delle dipendenze del progetto e le regole con cui si occuperà di scaricare e installare/aggiornare per noi questi pacchetti software all’interno del progetto.

Composer ha un repository ufficiale delle dipendenze, Packagist (<a href="https://packagist.org/" target="_blank">https://packagist.org/</a>), e un meccanismo nativo di gestione dell’autoload.

Questo il link al sito ufficiale del progetto: <a href="https://getcomposer.org/" target="_blank">https://getcomposer.org/</a>

Per poter utilizzare Composer dobbiamo procedere all’installazione; normalmente installiamo il tool a livello globale della macchina, posizionandolo in una cartella (ad es. usr/local/bin) specificata nella variabile d’ambiente $PATH, in modo che l’eseguibile (assicuratevi che lo sia dando i permessi necessari) sia disponibile ovunque.

Facendo riferimento all’ultima versione disponibile ad oggi e all’ipotesi di posizionare l’eseguibile Composer nella cartella ‘usr/local/bin’, in ambiente Unix (Linux, Mac OSX) sono sufficienti questi comandi:

<pre>$ sudo curl https://getcomposer.org/download/1.2.0/composer.phar -o /usr/local/bin/composer
$ sudo chmod +x /usr/local/bin/composer</pre>

L’approccio alla scomposizione del progetto in dipendenze, con Composer, si concretizza con due principali attività:

 che creiamo nella cartella di progetto e in cui elenchiamo i repository dove andare a recuperare i pacchetti e la lista di tutte le dipendenze, oltre ad alcune informazioni generali ed eventuali configurazioni avanzate sul progetto stesso. In questo file possiamo anche dichiarare degli script da eseguire al termine dell’installazione delle dipendenze.

Possiamo creare questo file manualmente oppure tramite il comando:

Per un approfondimento sullo schema del file composer.json fare riferimento a <a href="https://getcomposer.org/doc/04-schema.md" target="_blank">questo link</a>, per la lista completa dei comandi messi a disposizione dal tool fare riferimento a <a href="https://getcomposer.org/doc/03-cli.md" target="_blank">questo link</a>.

 occorre posizionarsi nella cartella in cui è presente il composer.json e lanciare da terminale il comando:

Questo comando scarica tutti i pacchetti dichiarati, li salva in una cartella chiamata “vendor” e crea un file autoload.php sotto la cartella vendor. Questo file è l’unico che necessita essere incluso negli script del progetto PHP.

Al termine della prima installazione delle dipendenze Composer crea il file 

 in cui vengono dichiarate tutte le dipendenze con indicazione della versione scaricata e installata.

Questo file può essere distribuito agli sviluppatori che vogliono replicare il progetto: sarà per loro sufficiente eseguire un composer install per assicurarsi di utilizzare gli stessi pacchetti e versioni dichiarati nel composer.lock.

Successivamente, in caso di modifica del file composer.json o di necessità di aggiornamento delle dipendenze dichiarate, andrà eseguito da terminale il comando

Questo comando scarica e installa le dipendenze che richiedono aggiornamento, rimuovendo la vecchia versione, e aggiorna il file composer.lock da distriibuire.

Come utilizziamo Composer con un progetto Magento?

Ma veniamo al sodo e vediamo come fare a pezzi un progetto Magento per poi lanciare un comando e trovarci magicamente di fronte un’applicazione funzionante (in realtà non è necessario alcun potere magico).

Parlerò dell’utilizzo di Composer con Magento 1, perchè Magento 2 ufficialmente supporta e incoraggia l’installazione tramite Composer.

Nel caso di un tipico progetto Magento, i “pezzi” a cui mi riferisco sono, ad esempio:

Come vedremo, il nostro progetto diventa a tutti gli effetti un 

 in quanto non conterrà codice PHP ma solo la definizione delle dipendenze di codice necessarie per il suo funzionamento.

Ecco il composer.json di esempio per un ipotetico progetto “magento_composer_example”:

<pre class="brush: jscript; title: ; notranslate" title="">{
"name": "bitbull/magento_composer_example",
"description": "Magento Composer Example Project",
"minimum-stability": "dev",
"authors": [
{"name": "Bitbull", "email": "devel@bitbull.it"}
],
"repositories":[
{"type": "composer", "url": "http://packages.firegento.com"},
{"type": "composer", "url": "http://packages.bitbull.it"},
{"type": "vcs", "url": "git@github.com:bitbull-team/mageploy.git"},
{"type": "vcs", "url": "git@bitbucket.org:bitbull/magento-translations-it.git"},
{"type": "vcs", "url": "git@bitbucket.org:bitbull/custom-example-modules.git"},
{"type": "vcs", "url": "git@bitbucket.org:bitbull/custom-example-theme.git"},
{"type": "vcs", "url": "git@bitbucket.org:bitbull/magento-deploy.git"},
{"type": "vcs", "url": "https://github.com/netz98/n98-magerun.git"},
{"type": "package",
"package": {
"type": "magento-module",
"name": "Acme_Module",
"version": "1.7.9",
"dist": {
"url": "https://bitbucket.org/bitbull/acme_module/get/v1.7.9.zip",
"type": "zip"
}
}
}
],
"require":{
"magento-hackathon/magento-composer-installer": "3.0.6",
"bitbull/magento-core": "1.9.2.4",
"bitbull/magento-cookienotice": "1.0.0",
"bitbull/magento-translations-it": "1.0.0",
"firegento/psr0autoloader": "dev-master",
"bitbull/composer-magento-example-modules" : "dev-master",
"bitbull/composer-magento-example-theme" : "dev-master",
"inchoo/php7": "1.0.3",
"bitbull/magento-deploy": "1.0.0",
"n98/magerun": "1.97.21"
},
"require-dev": {
"aleron75/webgriffe_tph-pro": "dev-master",
"pug-more/mageploy": "1.2.0"
},
"config": {
"secure-http": false
},
"extra":{
"magento-root-dir": ".",
"magento-deploystrategy": "symlink",
"magento-deploystrategy-overwrite": {
"bitbull/magento-core": "copy"
},
"magento-force": true,
"auto-append-gitignore": true
},
"autoload": {
"psr-0": {
"Bitbull": "lib/"
}
},
"scripts": {
"post-update-cmd": [
"Bitbull\Deploy\Magento::generateLocalXml",
"Bitbull\Deploy\Magento::setMaintenanceMode",
"Bitbull\Deploy\Magento::flushCache",
"Bitbull\Deploy\Magento::runUpgradeScripts",
"Bitbull\Deploy\Magento::reindexAll",
"Bitbull\Deploy\Magento::unsetMaintenanceMode"
],
"post-install-cmd": [
"Bitbull\Deploy\Magento::generateLocalXml",
"Bitbull\Deploy\Magento::setMaintenanceMode",
"Bitbull\Deploy\Magento::flushCache",
"Bitbull\Deploy\Magento::runUpgradeScripts",
"Bitbull\Deploy\Magento::reindexAll",
"Bitbull\Deploy\Magento::unsetMaintenanceMode"
]
}
}
</pre>

Vediamo nello specifico il significato delle principali direttive inserite nell’esempio; per la documentazione ufficiale e completa fate riferimento a <a href="https://getcomposer.org/doc/04-schema.md" target="_blank">questo link</a>:

La libreria magento-hackaton/magento-composer-installer

Questa libreria è la prima che includiamo in tutti i nostri progetti Magento poiché è studiata appositamente per installare moduli Magento tramite Composer, risolvendo alcune problematiche di integrazione.

è in grado di riconoscere e processare solo le dipendenze che rappresentano moduli Magento

; nel file composer.json delle singole dipendenze va impostata la tipologia di pacchetto specificando “magento-module”:

<pre class="brush: jscript; title: ; notranslate" title="">{
"name": "bitbull/magento-translations-it",
"type": "magento-module",
}
</pre>

Per noi il core Magento, il tema, tutti i moduli e la libreria che usiamo per le operazioni di deploy sono di tipo “magento-module”.

Per quanto riguarda il core di Magento, una soluzione alternativa è l’utilizzo del plugin <a href="https://github.com/AydinHassan/magento-core-composer-installer" target="_blank">Magento Core Composer Installer</a>, che nasce proprio per gestire il core di Magento come dipendenza installata con Composer, semplificando il mapping e ottimizzando la gestione del .gitignore.

Di default, in fase di installazione delle dipendenze, Composer scarica nella cartella vendor i file delle dipendenze; magento-composer-install replica questi file all’interno della root Magento in modo da creare la struttura di files e cartelle tipica di una installazione Magento standard.

Il metodo con cui rende disponibili i file dipende dalle configurazioni 

<pre class="brush: jscript; title: ; notranslate" title="">{
"extra":{
"magento-root-dir": ".",
"magento-deploystrategy": “symlink”,
"magento-deploystrategy-overwrite":  {
"bitbull/magento-core": "copy"
},
"magento-force": true
}
}
</pre>

Nel nostro caso indichiamo di deployare i moduli magento come link simbolici all’interno della struttura delle cartelle Magento, ad eccezione del pacchetto relativo al core di Magento che viene copiato.

Normalmente utilizziamo Modman per la specifica della mappatura della posizione dei files da replicare (per approfondimenti su modman <a href="https://github.com/colinmollenhour/modman/wiki/Tutorial" target="_blank">leggi questo tutorial</a>). Ulteriori opzioni sono la mappatura esplicita all’interno del composer.json oppure indicare, sempre nel composer.json tra le configurazioni “extra”, il file package.xml del modulo compilato secondo lo standard utilizzato da Magento Connect.

Questa strategia di deploy ha un comodo risvolto pratico.

Per il tema grafico e per i moduli con le personalizzazioni di progetto normalmente lavoriamo su due repository git separati (customer-project-theme e customer-project-modules) e, durante la fase di sviluppo, referenziamo le dipendenze facendo riferimento al branch master (dev-master).

In questo modo, sotto la vendor, abbiamo a tutti gli effetti due repository git su cui effettuare aggiornamenti, commit, ecc… e con la strategia di deploy “symlink” qualsiasi modifica ai pacchetti viene replicata in tempo reale sotto il path della root Magento in modo da poter lavorare senza necessità di effettuare un’operazione di composer update.

Inoltre, per chi come noi utilizza repository git, questa libreria consente di 

aggiungere in automatico al file .gitignore

 i riferimenti a tutti i file dei pacchetti integrati nel progetto come moduli magento (riconosciuti grazie alla configurazione della proprietà type).

<pre class="brush: jscript; title: ; notranslate" title="">{
"extra":{
"magento-root-dir": ".",
"auto-append-gitignore": true
}
}
</pre>

Questa integrazione con git è molto comoda poiché consente di avere nel repository git solo i files composer.json, composer.lock, .gitignore.

Come ulteriore feature la libreria consente di 

gestione dell’autoloading delle dipendenze

, tramite l’applicazione di una patch al core Magento (file app/Mage.php) che risolve l’inclusione del file di autoloading creato da Composer sotto la cartella vendor.

Questo comportamento, attivo di default, può essere disabilitato specificando la seguente configurazione:

<pre class="brush: jscript; title: ; notranslate" title="">{
"extra":{
"with-bootstrap-patch": "false"
}
}
</pre>

Quando creiamo una nuova estensione Magento, sviluppando ad esempio un modulo o il tema del cliente, ci adoperiamo per fare in modo che sia installabile come dipendenza tramite Composer.

Per fare questo è sufficiente includere un file composer.json che identifica il pacchetto, specificandone il nome (composto da vendor-name e package-name) ed eventuali ulteriori dipendenze.

Qui sotto ad esempio il file composer.json del modulo di traduzioni Magento di Bitbull.

<pre class="brush: jscript; title: ; notranslate" title="">{
"name": "bitbull/magento-translations-it",
"description": "Magento core and transactional e-mails translations in Italian",
"license":"MIT",
"type": "magento-module",
"authors":[
{
"name":"Lorena Ramonda",
"email":"lorena.ramonda@bitbull.it"
}
],
"require": {
"magento-hackathon/magento-composer-installer": "*"
}
}
</pre>

Come possiamo notare abbiamo dovuto specificare la proprietà 

 (dove “bitbull” è la vendor name) e la dipendenza con magento-hackaton/magento-composer-installer. Non è stato necessario specificare alcun repository in quanto l’unica dipendenza da soddisfare è recuperabile dal repository Composer ufficiale, Packagist.

Per indicazioni sulla creazione di librerie fare riferimento a <a href="https://getcomposer.org/doc/02-libraries.md" target="_blank">questo link</a>.

Tutte le funzionalità che potrebbero essere messe a fattor comune su diversi progetti vengono soddisfatte con moduli esistenti (community, Bitbull, altri fornitori) , distribuiti come pacchetti singoli, e quindi indipendenti dal progetto su cui è nata l’esigenza di integrazione.

Tutti questi moduli vengono referenziati nel composer.json facendo riferimento, per la versione, ad uno specifico tag.

I moduli custom del progetto (tema e personalizzazioni), come detto, vengono installati facendo riferimento al branch master dei relativi repository per poter essere aggiornati velocemente in fase di sviluppo.

Una volta pronti per il go-live creiamo una release, sia per questi moduli personalizzati sia per il meta-progetto, aggiungendo un tag alla versione corrente e specificandola nel file composer.json del pacchetto.

Scopo finale è avere, nel composer.json del meta-progetto, tutte le dipendenze con riferimento a tag specifici. In questo modo in caso di aggiornamento delle dipendenze non si rischia di integrare nell’applicazione versioni di codice non ancora testate o magari non compatibili.

Per una panoramica completa sulla specifica delle versioni il riferimento è <a href="https://getcomposer.org/doc/articles/versions.md" target="_blank">questo link</a>.

Usare Composer non è complesso, bisogna solo iniziare, e ragionare sempre in ottica di riutilizzo del codice, di pacchettizzazione dei propri sviluppi, di versioning e di flessibilità perché, come abbiamo visto, possiamo veramente integrare tutto il necessario, dal setup al deploy di un progetto.

Inoltre in un unico file abbiamo la visione di tutto quello che è installato nel progetto, una sorta di carta di identità e possiamo automatizzare le operazioni di aggiunta e rimozione di estensioni, riducendo gli errori dovuti inevitabilmente all’intervento manuale.

Composer: come “facciamo a pezzi” un progetto Magento

 è un gestore di pacchetti per il web, che comprende, tra gli altri, librerie JS e CSS, come Composer lo è per PHP.

Se utilizziamo spesso librerie di terzi nei nostri progetti, che vengono rilasciate con nuove versioni periodicamente, è utile avere un gestore di pacchetti perché ci consente di tenere aggiornate le nostre librerie all’ultima versione oppure di tornare indietro a specifiche versioni. Inoltre è molto utile usato insieme ad un 

 come Grunt o Gulp perché è possibile specificare tutte le librerie dipendenti all’interno del file bower.json per il progetto in essere in modo che sia sufficiente questo file per allineare il progetto su vari computer.

Anche nell’ipotesi di utilizzare un sistema di controllo di versione, basterà mettere sotto versione il solo file bower.json che ha tutti i riferimenti alle librerie utilizzate che verrano tirate giù in locale tramite un comando specifico che vedremo di seguito.

Un po’ come Composer, si compone di due parti:

Le dipendenze sono appunto i pacchetti (librerie/framework js/css etc..) contenuti nel 

 che è possibile installare tramite gli appositi comandi Bower.

Vediamo ora come generare il bower.json ma prima assicuriamoci di aver installato Bower. Se avete già node.js installato (sennò 

 e va utilizzata la prima volta soltanto per installare Bower a livello globale sulla macchina in modo che il comando 

 sia poi disponibile ovunque nel sistema).

Fatto ciò, ovunque nel terminale digitando 

 dovremmo ottenere il numero di versione. Anche questo è bene ogni tanto aggiornarlo.

Ora siamo pronti per configurare Bower. Ci portiamo nella cartella del progetto (poi starà a voi scegliere in quale posizione è meglio collocare i file, ma mediamente si mette allo stesso livello del task runner e delle cartelle di output dei JS e CSS compilati per non dover digitare URL infinitamente lunghe o complicate come vedremo poi).

Per generare il file bower.json ci viene in aiuto un suo comando nativo (molto comodo):

Questo lancia la procedura di compilazione del file, ci verranno chieste un po’ di informazioni:

Per sapere cosa sono i moduli Javascript 

 che lo spiega molto bene, ma in buona sostanza significa scrivere codice riutilizzabile e distribuibile, dove ogni modulo è costituito da un gruppo di file che insieme implementano una specifica funzionalità. Quindi qui si tratta di definire quale “metodo di scrittura codice” verrà utilizzato.

"authors": [
  "Bitbull",
  "Bitbull &lt;info@bitbull.it&gt;",
  "Bitbull &lt;info@bitbull.it&gt;; (http://bitbull.it)"
]

Oppure si può scrivere anche in questo modo:

"authors": [
  { "name": "Bitbull" },
  { "name": "Bitbull", "email": "info@bitbull.it" },
  { "name": "Bitbull", "email": "info@bitbull.it", "homepage": "http://bitbull.it" }
]

L’intervista è finita. Bower ti propone ora la bozza di quanto generato sulla base delle tue risposte. Se è tutto corretto puoi confermare con Y.

Ecco un esempio di un bower.json completo:

A queste info è possibile aggiungere il riferimento al repository se presente:

"repository": {
  "type": "git",
  "url": "git://github.com/bitbull-team/bower-spiegato-ai-backend.git"
}

Ora si può passare all’installazione dei pacchetti che ci servono, prendiamo per esempio il classico jQuery.

Se conosciamo già il nome del repo possiamo installarlo direttamente altrimenti è possibile fare una ricerca direttamente da terminale con:

Ne verrà fuori una sfilza che non finisce più, normalmente quello corretto/ufficiale si trova in alto, ma verifichiamo sempre che il repo sia giusto:

jQuery https://github.com/jquery/jquery.git
jquery https://github.com/jquery/jquery-dist.git
jquery.x https://github.com/jljLabs/jquery.x.git
jquery.Q https://github.com/jsbuzz/jQuery_Q.git
jt_jquery https://github.com/vicanso/jt_jquery.git
jquery-m https://github.com/meetup/jquery.git
[..]

Installiamo perciò il primo ricordandoci di usare la dicitura 

 che ci assicura che venga inserito nelle dipendenze richieste in produzione:

Il nostro bower.json avrà in fondo ora un blocco in più:

Bitbull

Tools

Git Flow: come funziona aka Back to the future

Algolia su Magento

Composer: come “facciamo a pezzi” un progetto Magento

Bower spiegato ai back end developer

Migrazione dati da Magento 1 a Magento 2

Sul mio computer funziona

Si fa presto a dire “deploy” !