[Gruppo-web] Spiegazione implementazione nuovo sito

Sab 3 Maggio 2014 23:54:46 BST

Ciao a tutti,
vi scrivo questa mail per spiegarvi come Mattia ed io abbiamo pensato di implementare lo sviluppo del nuovo sito. Ovviamente tutti i consigli sono ben accetti :-)

Innanzitutto bisogna ricordarsi che il nostro obiettivo principale è separare completamente lo sviluppo del tema dal mantenimento del sito, perché vogliamo rendere il tema disponibile anche ad altre comunità.
Tutte le scelte che descriverò di seguito sono state fatte con questo obiettivo in mente, ma cercando di mantenere lo sviluppo e l'inclusione del tema i più semplici possibili.

Prima di procedere però vorrei spiegarvi un attimo come sono disposti i nostri server, informazioni di per sé inutili allo sviluppo del sito, ma credo possano essere interessanti anche perché potrebbero venire fuori i nomi ogni tanto.
Dunque, il sito attualmente è ospitato su un server Canonical, chiamato magog, gestito dai sysadmin Canonical. Fino a che non faremo il nuovo sito, il mantenimento di quello vecchio sarà fatto alla solita maniera, su Launchpad. 
Il sito di test[1] è invece ospitato su un server gentilmente concesso da TOP-IX, chiamato roadhouse, gestito dal Gruppo Sysadmins di ubuntu-it. Il server, che funziona con Debian, ha al suo interno vari contenitori grazie a lxc. Per semplicità potete considerare ogni contenitore come un'istanza di un sistema separato. Il contenitore su cui gira il sito di test si chiama bromuro e, del Gruppo Web, solo io ho accesso.
Una volta che vorremo sostituire il sito attuale con il nuovo sito, cloneremo bromuro in un nuovo contenitore e (dopo qualche modifica) quello sarà il nostro sito di produzione. bromuro rimarrà il nostro sito di test.
Questo è quanto per quello che riguarda i server.

Ora, passiamo al tema. 
Il tema, chiamato valencia, è hostato su GitLab[2]. Perché Git e non Bazaar? Beh, chiunque abbia usato seriamente entrambi sa il perché, per gli altri sappiate solo che Git è diversi gradini sopra a Bazaar.
Tornando a bomba sul tema, è diviso in due branch: il branch dev[3], che è quello di default, è quello su cui sviluppiamo ed è quello sincronizzato con il sito di test (su questo tornerò dopo) e il branch master[4], che manterrà solo le versioni stabili del tema e con i quali sarà sincronizzato il server di produzione.
Per facilitare l'inclusione del tema in varie installazioni di Drupal, invece che git submodule (che è un incubo a occhi aperti) abbiamo optato per Composer[5] che in pratica permette di gestire un repo come un pacchetto. Una finezza. Per chi volesse dare un'occhiata all'implementazione, qua c'è il file[6], davvero basilare.
Questo cosa cambia per lo sviluppo del tema? Assolutamente nulla! Quando fate una modifica, pushatela, basta (dopo vediamo cosa c'è invece da fare per quanto riguarda le installazioni di Drupal).
In questo modo anche altri team possono includere facilmente il tema nella loro installazione di Drupal. 
Per quanto riguarda lo sviluppo del tema Mattia ha già scritto alcune email ieri, dateci un'occhiata. Nei prossimi giorni io e lui continueremo a svilupparlo, se ci date una mano siamo più che felici :-)
Prima però cercate di coordinarvi con lui tramite G+ (magari con chi è interessato facciamo una chat di gruppo). Se invece non avete tempo per lavorare sulla base del sito, Mattia ha già comunque provveduto ad aprire alcuni bug[7] (e altri verranno sicuramente aggiunti nei prossimi giorni). Sul repo di valencia, visto che vuole essere pubblico, vi chiederei di scrivere in inglese (anche i commenti nel codice). Grazie.

Last but not least, passiamo al sito stesso. Il repository del sito di produzione non esiste ancora, quindi per non aumentare la confusione per ora non ne parlerò.
Per quanto riguarda il sito di test, abbiamo un repository dedicato[8]. Per installarlo in locale fate come al solito, in ogni caso se volete sviluppare il tema DOVETE averlo in locale (non necessariamente installato). Una delle cose comode di Git è che quando viene fatto un push si può impostare un hook che lanci uno script. Cosa vuol dire? Che ogni volta che fate un push su questo repository, in automatico il sito di test viene aggiornato. Non dovete quindi aspettare che un cron entri in funzione, come è adesso. Pushate, il sito è aggiornato. Fantastico.
C'è però da aggiungere il tema ai sorgenti (ricordate? Il tema è separato dalla gestione del sito, quindi il codice non è incluso nel repository).
Difatti come potete vedere il tema viene ignorato da Git[9]. Come si fa ad aggiungere? Beh, grazie a Composer! Se guardate nei sorgenti abbiamo 3 file: composer.phar[10], composer.json[11] e composer.lock[12]
composer.phar è un file che ci permette di dare comandi a Composer, composer.json invece è il file di configurazione di Composer (dateci un'occhiata, ma dovrebbe essere a posto), composer.lock invece indica quale versione del pacchetto (in questo caso di valencia) deve essere inclusa. Questo permette a tutti gli sviluppatori e a tutti i server di avere la stessa versione del tema. Intelligente, nevvero?

Per installare il tema in locale e aggiornarlo basta utilizzare il seguente comando:

php composer.phar install

Quando volete quindi aggiornare la vostra installazione locale di Drupal basta che diate:
git pull
php composer.phar install

Facile e pulito, no? Come vedete tutto quello che dovete fare è solo dare un comando in più.
php composer.phar install prende i dati da composer.lock, in questo modo tutti sono ancorati alla versione inserita in .lock.

Supponiamo però che abbiate aggiornato il tema (e quindi abbiate pushato qualcosa di nuovo nel repo di valencia, branch dev). Come fate ad indicare a Composer di prendere la nuova versione?
Entrate nel repository di Drupal (www-test) e date il seguente comando:
php composer.phar update

Questo vi scarica l'ultima versione di valencia e aggiorna il file composer.lock.
Dovete quindi pushare il file composer.lock sul repo:
git add composer.log
git commit -m 'Updated theme to version NUMBERofVERSION'
git push

Ed ecco fatto: il server di test si aggiornerà all'ultima versione del tema, così anche le installazioni degli altri sviluppatori quando aggiorneranno il loro tema con
git pull (per recuperare la nuova versione di composer.lock)
git composer.phar install

Il fatto di avere gli hook significa che l'aggiornamento del sito è immediato, quindi potete usare il sito senza installare Drupal in locale, perché tanto vedete le modifiche immediatamente.
Non è il modo migliore di lavorare, ma per modifiche minori è accettabile. Certo, state attenti a non rompere tutto :-)

Prossimamente scriverò una guida su questo (o se qualcun altro la vuole fare, grazie mille), nel frattempo considerate questa mail come la documentazione più recente che avete.
git submodule non serve più, se è ancora scritto da qualche parte.

Per qualunque dubbio, anche quello che vi sembra più scemo, chiedete pure qua :-)

Scusate il lungo papiro, ma io e Mattia abbiamo parlato a lungo e volevo mettervi al corrente di tutte le novità. Spero di essere stato abbastanza chiaro e di non essermi dimenticato niente, vista l'ora tarda.
Ricordatevi che abbiamo anche #ubuntu-it-web se volete fare due chiacchere ;-)

E ora forza, al lavoro!
Buonanotte,

[1]http://wwwtest.ubuntu-it.org
[2]https://gitlab.com/ubuntu-it-web/valencia
[3]https://gitlab.com/ubuntu-it-web/valencia/tree/dev
[4]https://gitlab.com/ubuntu-it-web/valencia/tree/master
[5]https://getcomposer.org/
[6]https://gitlab.com/ubuntu-it-web/valencia/blob/dev/composer.json
[7]https://gitlab.com/ubuntu-it-web/valencia/issues
[8]https://gitlab.com/ubuntu-it-web/www-test/tree/master
[9]https://gitlab.com/ubuntu-it-web/www-test/blob/master/.gitignore
[10]https://gitlab.com/ubuntu-it-web/www-test/blob/master/composer.phar
[11]https://gitlab.com/ubuntu-it-web/www-test/blob/master/composer.json
[12]https://gitlab.com/ubuntu-it-web/www-test/blob/master/composer.lock
-- 
Riccardo Padovani
www.rpadovani.com