Home

Welcome to the HomeCheck wiki!

Project: Web app per la gestione della dispensa casalinga, inventario dei prodotti, gestione delle scadenze

Group ID: 02

Team members:

• Lechthaler Marco
  • 201752
  • marco.lechthaler@studenti.unitn.it
  • MarcoLech
• Momesso Filippo
  • 201604
  • filippo.momesso@studenti.unitn.it
  • Momofil31
• Rossi Daniele
  • 201646
  • daniele.rossi-1@studenti.unitn.it
  • DanieleRossi

Links

Link Github: https://github.com/Momofil31/HomeCheck

Link Wiki: https://github.com/Momofil31/HomeCheck/wiki

Link Apiary: https://homecheck.docs.apiary.io/

Link Heroku:

• API: http://homecheck-api.herokuapp.com/v2/
• Client: https://homecheck-vue.herokuapp.com/

Organizzazione repository

Il repository del progetto contiene tutto il codice sorgente necessario a far funzionare l’applicazione. Nella root del progetto si trova il file swagger.yml che contiene la descrizione dell’api secondo la specifica OpenAPI 3.0, il file di configurazione di Travis e il .gitignore.

Il codice vero e proprio è diviso nelle cartelle “server” e “client”. In server si ha l’API RestFul mentre in client si ha la single page application Vue.

Architettura

Il progetto segue le specifiche architetturali richieste. L’applicazione client e l’API girano in due server separati. Il database MongoDB si trova anch’esso in un server separato in quanto utilizziamo il cloud Mongo Atlas.

Quando l’utilizzatore finale utilizza l’applicazione, questo, attraverso il browser, interagisce con il client il quale invia le richieste HTTP necessarie alle API RestFul. Quest’ultima interagirà con il database remoto situato sul cloud Mongo Atlas tramite le primitive fornite dal pacchetto Mongoose.

Strategia di branching

Il repository è suddiviso in due branch: master e develop. In master viene committato tutto ciò che è finito (done) mentre in develop si trova tutto il codice delle features non ancora done. Il motivo di questa scelta risiede nel fatto che master è il branch che contiene il codice di cui sarà fatto il deploy automatico tramite Travis.

Non è stato scelto di utilizzare una strategia del tipo GitFlow perché avrebbe reso troppo complicata la gestione del repository. Data la dimensione ridotta del nostro team e la non eccessiva complessità del progetto non aveva senso utilizzare strategie di branching più complesse.

Definizione di “done”

• Codice testato sulla macchina in locale
• Codice testato da altri membri del team
• Aver scritto Integration and System Test e il codice deve aver passato i test.
• Documentazione (Apiary) scritta e revisionata
• Codice committato e merged sul branch master