Task aperti

Nella configurazione di stage quattro valori di One Platform sono ancora dei segnaposto (TBD-): l'indirizzo del servizio, quello per il token, l'identificativo del client e il codice prodotto. Arriveranno dalle risposte di FairConnect del Task 110.

La cartella di produzione elenca una ConfigMap che non esiste, e quella di sviluppo è vuota: vanno scritte tutte e due.

Resta aperta con FairConnect la domanda su come la loro pipeline pubblica in stage. Oggi il suo script pubblica solo dal ramo develop, verso l'ambiente di sviluppo.

Su stage e produzione il corredo va caricato a mano dalle maschere di amministrazione, perché lì i dati di esempio non vengono applicati.

I tre PDF contrattuali non stanno nel repository: vanno ricopiati a mano su ogni ambiente nuovo.

Le anagrafiche del primo rilascio (partner, sedi e venditori) non esistono ancora. Non si inseriscono da noi: arrivano dalla sincronizzazione con PAD.

Lo storico e il blocco della vendita ci sono già. Manca la terza fase: la mail che avvisa quando la formazione sta per scadere. Il piano è scritto, ma non c'è ancora una riga di codice. Serve anche il nome dell'evento e del modello di mail che deve darci FairConnect (Task 110).

Non è mai partita la parte sull'informativa precontrattuale, che deve riportare da sola il codice RUI, la sezione e la data di iscrizione del venditore.

Prima di chiudere il task restano due verifiche: che su stage e produzione i dati dei venditori siano quelli attesi al rilascio, e una prova completa in locale partendo dai dati.

Il codice va consegnato ai repository di FairConnect: l'ultima consegna del backend è del 21 settembre, il codice del cluster è del 23. Nello stesso giro va committata la configurazione di stage con l'elenco dei nodi, che oggi è modificata ma non committata.

Quando l'immagine nuova gira in stage, si tolgono dalla configurazione il vecchio host e la vecchia porta. La configurazione di produzione non esiste ancora (Task 109): quando nasce deve portare l'elenco dei nodi.

Infine va misurato in stage se il timeout di 2 secondi basta con la latenza vera della VPN.

Cinque task su otto sono consegnati: la cornice, gli operatori, i clienti, i segnalatori e i dealer. Restano venditori, sedi e partner.

Il lavoro è diviso in sei blocchi: prima backend e BFF di ciascuno dei tre, poi i tre frontend. Sedi e partner devono uscire insieme, perché disattivare una sede o un partner si ripercuote a cascata sugli utenti collegati.

Prima di partire con i venditori serve la code review di backend e BFF dei dealer, che fanno da modello. Poi una review alla fine di ogni blocco, una sulle cascate di sedi e partner prima del loro rilascio e la rilettura finale dei piani.

I 18 casi della bozza sono stati scritti leggendo il codice: vanno eseguiti sull'applicazione vera. Solo dopo si toglie la scritta «BOZZA».

Mancano i casi della vendita del solo dispositivo, e vanno controllati a mano in Excel i totali del foglio di riepilogo.

Il blocco del backoffice può partire solo quando il Task 145 sarà consegnato.