Development Process & Tools

Una serie di regole e accorgimenti che ci possono aiutare nel semplificare e velocizzare il processo di sviluppo

1. Sviluppo

2. Condivisione e versioning del codice

3. Test e pubblicazione

Server di sviluppo

facilmente manutenibile (c’è tutto e va bene per tutti i componenti del team)

minor costo di startup del progetto

piace ai designer

ma….

Server di sviluppocontrollo di versione MANUALE! -> “Ho fatto delle modifiche, prima di cominciare controlla…”

collaborazione difficile se non impossibile -> “Mi lasci il server che devo provare una cosa?!”

rallentamento nello sviluppo -> Modifica, pubblica, testa, rimodifica e ripubblica…. E rimodifica….

minore libertà nello sviluppo -> “Chi ha modificato il codice?! Non funziona niente!”

Server di sviluppo

Va usato….

Quando è impossibile testare una funzionalità in locale (es. integrazione con sistemi esterni)

Quando è finito lo sviluppo e dobbiamo testare in un ambiente simile alla produzione. Così non potremo dire “da me funzionava” :)

Test di carico

etc.

Server di sviluppo

Ma così come collaboriamo?

Come condividiamo le modifiche?

Usa git… Luke!

Perché Git?Sistema di versioning distribuito (copia in locale della repository)

Versioning locale e remoto (commit e push)

Branching veloce

Usato da molti PAAS per la pubblicazione (in produzione con un push)

Aiuta nelle CODE REVIEW!!

Occhio però…

Se usato “A cazzo di cane!” non ci aiuta e può anche causare diversi problemi!

(Chiedete al P.O. per conferme)

Git flow

Ovvero, come organizzare il nostro flusso di lavoro in

git evitando di avere codice di produzione

non funzionante

Git flow (2)master: codice in produzione

develop: branch “base” da cui partire per sviluppare

hotfix: utilizzati per fix urgenti in produzione

feature: branches contenenti nuove funzionalità in sviluppo

release: nuove versioni da pubblicare (possibilmente a fine sprint)

Git flow (3)

Quando deve rientrare del codice dai branch in release e develop usiamo le

PULL REQUEST perché ci permettono

di fare CODE REVIEW

wordpress + git startup

cloniamo la repository di wordpress

inizializziamo la nostra su wp-content

modifichiamo il .gitignore escludendo tutto quello che non deve essere sotto controllo di versione

… (suggeriment?!)

E alla fine pubblichiamo…

Una volta che i fix o features sono pronti, possiamo pubblicare su un server di “testing”

Se abbiamo git sul server, facciamo un push delle modifiche

Se abbiamo ssh possiamo utilizzare tools per il publishing (es. capistrano)

Se abbiamo solo ftp (DOH!!), possiamo (che si legge DOBBIAMO) automatizzare con degli script

E alla fine pubblichiamo… (2)Se tutto funziona in “testing” possiamo andare in produzione

La pubblicazione in produzione è uguale a quella in testing (occhio ai file di configurazione)

Il codice in produzione non DEVE differire da quello di testing, altrimenti si rompe tutto!