A small introduction to tools and conventions needed for an agile development process

1. Development
Process & Tools
Una serie di regole e accorgimenti che
ci possono aiutare nel semplificare e
velocizzare il processo di sviluppo

2. 1. Sviluppo
2. Condivisione e versioning
del codice
3. Test e pubblicazione

3. 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….

4. Server di sviluppo
controllo 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!”

5. Server di sviluppo
Va usato….

6. Server di sviluppo
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.

7. Ma così come
collaboriamo?
Come condividiamo
le modifiche?

8. Usa git… Luke!

9. 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!!

10. Occhio però…
Se usato “A cazzo di cane!”
non ci aiuta e può anche
causare diversi problemi!
(Chiedete al P.O. per
conferme)

11. Git flow
Ovvero, come
organizzare il nostro
flusso di lavoro in
git evitando di avere
codice di produzione
non funzionante

12. 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)

13. 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

14. 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?!)

15. 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

16. 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!