Oboxo: social crowd shop

Oboxo è una piattaforma multi-ecommerce che offre un servizio aperto ai rivenditori che vogliono svolgere la propria attività su un medesimo marketplace online.

Il servizio basa la sua originalità su un corredo di funzionalità social, attraverso le quali gli utenti possono creare e condividere collezioni di prodotti e accumulare revenue divenendo promoter attivi di negozi e beni.

La realizzazione del progetto ha presentato sfide varie e stimolanti dal punto di vista tecnico: dall’integrazione con i social network, all’interfacciamento con gateway di pagamento online e con i sistemi di spedizione di UPS.

Oboxo è una piattaforma che segue il processo di vendita dalla creazione dei cataloghi di vendita, all’allestimento delle vetrine, alle transizioni correlate all’acquisto fino all’atto della spedizione vera e propria.

Anche in questo caso, l’impiego di tecnologie open source e la nostra confidenza con il framework Symfony 2 hanno permesso di raggiungere gli obiettivi richiesti senza subire ritardi vincolanti sui tempi di messa online della piattaforma.

Symfony 2

Il framework open source Symfony 2 è stato creato per permettere lo sviluppo di applicazioni con un occhio di riguardo alla manutenibilità e alla testabilità del codice, elementi chiave del Test Driven Development e dello sviluppo Agile.

L’impiego del Framework, ha reso possibile l’abbattimento dei tempi di sviluppo, facilitando anche lo scambio di conoscenze fra i membri del team.

La navigabilità di una code base comune, inoltre, semplifica drasticamente la ricerca di professionisti da inserire su un progetto in corso d’opera o succesivamente alla sua consegna in fase manutentiva.

Kanban board

La nostra esperienza unita a quella del team Oboxo è stata cruciale nella definizione delle soluzioni tecniche adottate e nell’organizzazione dell’attività lavorativa.

Abbiamo sviluppato il nostro processo produttivo attraverso l’impiego di una board di avanzamento lavori inspirata al Kanban che è diventata il costante punto di riferimento per il nostro lavoro, permettendo anche ai team di sincronizzare le proprie attività e focalizzarsi maggiormente su quelle capaci di rilasciare il maggior valore possibile nel minor lasso di tempo.

Per la condivisione della Kanban board fra i team abbiamo utilizzato Trello strutturando le colonne in ordine di priorità dividendole in: Backlog, Todo, Doing, Quality assurance, Deploy.

Intendendo le feature come l’unità base di un processo di lean manufactoring e avendole descritte attraverso una suite test di accettazione è stato possibile organizzare il lavoro del team, permettendo di accellerare i tempi di sviluppo in modo che le risorse potessero lavorare indipendentemente senza creare roadbloack o dipendenze temporali nel proccesso di sviluppo.

Continuous delivery

Il progetto è stato sviluppato da un team eterogeneo composto dalle nostre risorse e quelle di Oboxo in un’ottica di collaborazione e continous delivery.

Questo vuol dire che l’elemento chiave della pianificazione è sempre stata l’individuazione e la prioritizzazione delle attività che portassero il maggior valore aggiunto al cliente, facendo dell’iterazione continua e dell’immediata verifica funzionale dei rilasci il fulcro di ogni decisione tecnica e strategica.

Test Driven Development

Il nostro metodo di lavoro si fonda sulle metodologie agili: il test è la base di partenza per lo sviluppo di nuove feature, e diventa il vero punto di incontro fra le richieste del cliente e il team di sviluppo per garantire che il software abbia sempre l’insieme minimo di funzionalità richieste.

Symfony 2 mette a disposizione numerosi strumenti che facilitano la scrittura di test funzionali e unitari, rendendo possibile il lavoro snello e il mantenimento di un alto profilo qualitativo del software.

Fra gli strumenti utilizzati per la scrittura delle suite di test a corredo del software rilasciato c’è Behat Mink attraverso i driver Selenium 2 e la classe WebTestCase del FrameworkBundle di Symfony 2.

 

Selenium 2 è uno strumento che permette di pilotare un vero browser in ambiente grafico in modo da poter testare appieno la funzionalità dell’interfaccia attraverso diversi applicativi (ad es. firefox, chrome, phantom-js) in maniera trasparente e senza dover riscrivere l’intera suite di test.

Questo permette di testare e navigare il markup delle pagine web visualizzate sul portale, consentendo anche interazioni complesse ad esempio come la login o la compilazione di un modulo.

Software versioning

Attraverso il controllo di versione è possibile mantenere diverse istantanee di una stessa code base, rendendo possibile il mantenimento e lo sviluppo continuo del software anche quando diverse risorse sono allocate sulle medesime funzionalità, evitando il rischio di sovrascrittura, regressioni e perdita di dati.

Lo strumento che usiamo per il controllo di versione è Git, mentre il repository progetto è stato ospitato su Github.

Database migrations

Mantenere il controllo di versione sul codice sorgente è una pratica utile, ma spesso e volentieri non pienamente sufficiente.

E’ necessario, infatti, mantenere il set di dati a corredo dell’applicazione (per i quali potrebbe bastare un dump), ma anche le metainformazioni che costituiscono la struttura stessa del database che possono cambiare in corso d’opera.

Per risolvere questo problema, la scelta è ricaduta sul Doctrine Migration Bundle, un bundle per Symfony che porta all’interno del framework la funzionalità della libreria Doctrine Database Migration.

Installare il bundle in un progetto Symfony 2 è semplice e immediato quanto dichiarare le dipendenze nel file composer.json, indicando nelle direttive del file di renderlo disponibile nel progetto.

Questo bundle fa uso del concetto di migrazione, per permetterci di mantenere il codice sorgente allineato allo schema del database.

Una migrazione è la codifica sotto forma di sorgente applicativo di un set di operazioni sulla struttura della base dati, che possono dunque essere eseguite iterativamente per  ripristinarla ad uno stato precedente “downgrade” o portarla in uno stato successivo “upgrade”.

Per ogni variazione apportata alle entità di Doctrine possiamo decidere di generare una nuova migrazione che fissi le modifiche che andranno a riflettersi sulla struttura del database.

Ciascuna migrazione verrà dunque salvata dal sistema che la ordinerà temporalmente per poi renderla disponibile in uno stack di operazioni di downgrade ed upgrade direttamente invocabili da linea di comando attraverso la console di Symfony 2.

Grazie al Doctrine Migration Bundle è dunque possibile poter mantenere il codice sorgente allineato allo schema del database con poco sforzo – si tratta di lanciare un paio di comandi di export ed import per generare o ripristinare una migrazione – a patto di aver usato Doctrine come layer di persistenza per la gestione della base dati.

Conclusioni

L’utilizzo delle buone pratiche di sviluppo – come ad esempio continuous delivery, continuos integration, kanban board, software versioning, test driven development – permette di poter rilasciare software funzionante e che corrisponda alle esigenze espress dal cliente, riducendo il tempo dei rilasci e permettendo di avere un feedback costante e frequente evitando errori di comunicazione e permettendo agli stakeholder di prendere decisioni rapide e baste sulle metriche di utilizzo del software oltre che dai feedback degli utenti a cui il prodotto è rivolto.