Class Project

File registrazione gruppi: https://docs.google.com/spreadsheets/d/16Ga3PlOPkuuKfJMhlnokvvK3sFG4b3V9q8RuyUaMlNI/edit?usp=sharing

Gruppi: 4-5 persone, idealmente.

Il tema del progetto e' stato descritto in classe, se avete dubbi sui requisiti - o su altri aspetti, aggiungete commenti in questo documento (UNITN login required)

I gruppi:

• Definiscono API, che si discute poi insieme. Le API devono essere versioned, perche' potranno cambiare durante il progetto.
• Definiscono stories e piano di implementazione
• Definiscono casi di test per le API e le mettono nel CI environment
• Scrivono integration test cases

Il gruppo si divide internamente il lavoro di implementazione e di testing, ma tutti devono avere commits visibili su github.

Ogni gruppo ha un solo GitHub. OGNI membro del gruppo scrive sia codice che test cases, e la cosa deve trasparire da commit fatti dallo studente visibili su GitHub

Il gruppo fa setup di CI environment (tutti devono saperlo fare, anche se il CI e’ uno per gruppo).

Wiki

Il progetto ha una wiki, pubblica o privata a vostra scelta (comunque su github) che descrive obiettivi e contiene puntatori a:

• API description document (su apiary)
• Applicazione su Heroku
• Github repository
• La descrizione del progetto ( come lo avete compreso) e della parte del progetto che voi realizzerete

La wiki contiene inoltre i nomi dei partecipanti al progetto

Deadlines:

• 31 ottobre (entro 10am):
  • Github repository creato (eventualmente privato, se preferite), e link inserito sul file di registrazione
  • Apiary file (in swagger language) creato e messo sotto version control sul github repo
  • Applicazione "vuota" che risponde "hello world" o quello che volete, deployed su heroku (mettete il link a vostra heroku app sul solito registration file)
  • github wiki contenente per ora almeno i nomi del gruppo e dei partecipanti, link a apiary, link a heroku
  • ogni perona del gruppo deve fare una modifica a un file qualunque, ma uno stesso file (ad esempio un readme.md o readme.txt, dove ciascuno aggiunge il proprio nome e fa commit) e fare push sul github repo
  • se il repo e' privato, condividetelo per cortesia con fabiounitn and jorgeramirez

• 7 novembre, entro le 9am
  • travis account set up. file .travis.yml presente sul repo. *tutti* i membri del gruppo devono avere account travis set up (questo dovreste averlo gia' fatto a lezione)
  • create una branch chiamata develop (rendetela visibile su github)
  • create DUE app su heroku,
    1. una configurata per fare deploy automatico dalla branch develop su github, DOPO avere passato i test (con il tick su "Wait for CI to pass before deploy")
    2. l'altra per fare deploy manuale da master - questa sara' la nostra "production version"

• 14 novembre, entro le 9am
  • API per il tema del progetto scritte in swagger, almeno a livello di REST resources, non e' necessario specificare per ora il formato degli oggetti che vengono passati
    • ad esempio, per un app di movie search vorrei vedere API per /movies, /cinemas, /cinemas/{id}, con per ogni operazione una brevissima desc e le risposte possibili con http status codes
    • se avete dubbi sul linguaggio per API specification, potete anche fare riferimento a https://swagger.io/docs/specification/about/ per un aiuto
  • definizione di un project su github, e vi consiglio di utilizzare il template automated kanban
  • user stories per ll servizio che dobbiamo realizzare, specificate come issues su github. Per la parte "how to demo" delle storie, scrivetela dentro le stories (dentro gli issues in guthub). Mi aspetto da voi le user stories, se avete dubbi chiedete. NON vi daro’ una lista dei requirement da implementare, definite voi le stories sulla base di quello che vi ho raccontato e se avete dubbi da chiedere ai "customers" (io e jorge), chiedeteci
  • NB: non importa che siano perfette, Lo stiamo facendo come esercizio e siamo qui per imparare, ma e' importante che ci dedichiate del tempo. Pensateci, con cura, e proponente API e storie "ragionate", a valle della lettura della documentazione fornita su API e scrum. Quello che non potete fare e' scrivere due cose velocemente solo per dire "fatto".
  • 21 novembre, 9am:
    • Definizione di issues nel backlog (Vi consiglio di creare un issue su github per [metodo, verbo] (ad es, POST su /users), assegnarlo alla persona del team che deve farlo)
    • Issues assegnati a persone (vedi sotto)
    • APi completata, da implementare su apiary e come sempre committed su github
  • Con descrizione e schema per i parametri

• Nota: Una cosa che potete fare ad esempio e’ assegnare a ciascun membro del gruppo una collection e una risorsa, ad es, una persona implementa GET e POST su /users e GET, PUT, DELETE su /users/{id}.
• Notate che mentre in una implementazione “completa” partiremmo dalle vostre user stories e le scomporremmo in sub-tasks, qui non faremo il client (nel senso di UI). Siccome ci concentriamo su API e NON completeremo realmente stories, possiamo quindi per il progetto semplicemente creare un issue su github per ogni [metodo,verbo] (ad es, un issue per post su /users.

Issue si intende completato quando sono stati scritti i casi di test, il codice, e il codice passa i tests. Ma in questa fase non dovete implementare o testare, solo preparare gli issues.

• 28 novembre:
  • Ciascun membro del gruppo, almeno per un paio di verbi http per uno URI, scrive test cases per le API (con commit su github), e successiva implementazione - con commit sulle feature branches e merge su develop
  • Deploy su github / develop
  • Per lo sviluppo useremo Gitflow come modello
  • Ricordate di rendere visibili le vostre branch su github facendo anche push della branch
  • [Nota: se preferite scrivere codice prima di scrivere i casi di test lo potete fare, ma il consiglio e' di partire dai test]
  • [e un altra nota: se fate strato di API "leggero" (solo unpacking dei parametri) e implementazione della logica in un altra funzione, spesso si parte dalla funzione e si testa questa, e poi si testa la parte di API on top, ma potete fare come preferite
• 5 dicembre, 9am
  • test+implementazione di altre API, per arrivare a 4-5 in totale. cercate di implementare un set di metodi in modo da potere fare una serie di operazioni logiche. ad esempio, aggiungere uno user, poi definire un task, assegnarlo, etc.
• 12 dicembre, 9am
  • Leggere il codice di almeno due altri gruppi e commentare secondo lo schema indicato in questo gdoc.
  • Compilare (due volte) la form https://goo.gl/forms/ineIvlF4az6MPpU73
  • mi aspetto che dedichiate almeno 45 minuti per gruppo
  • Scegliete il gruppo da visionare come spiegato a lezione
  • NB: per il progetto NON E" necessario completare l'implementazione di tutto: basta che ciascuno di voi abbia completato 4-5 coppie (risorsa, verbo), compresi casi di test, e che il tutto sia testabile

Se avete dubbi, sapete dove trovarmi, non esitate a chiedere