Conservazione dei codici di conservazione delle best practice?

"Recentemente abbiamo iniziato la migrazione" sembra che non stiamo parlando di codice molto vecchio qui. Inoltre, "una tonnellata di piccole app della nostra eredità" suggerisce un'elevata complessità e una maggiore disponibilità di tempo.

Quindi ci sono alcuni buoni argomenti per ascoltare i tuoi sviluppatori:

• In un paio di settimane, potresti riscontrare problemi a causa di casi d'uso o interazioni imprevisti o errori durante la migrazione che interessano solo situazioni rare. Sarà quindi più veloce analizzare il problema con la mappatura negli strumenti di migrazione a portata di mano. E forse sarà necessario rimigrare o aggiornare le parti secondarie di alcune strutture di dati migrate. Sarebbe un peccato ricominciare da capo.
• Forse i tuoi sviluppatori hanno già identificato alcuni pezzi di algoritmi che potrebbero essere riutilizzati. Dopotutto, sono gli stessi dati.
• Potrebbero esserci alcuni motivi legali che richiedono a scopo di controllo che i tuoi programmi di migrazione vengano conservati per un po 'di tempo (ad esempio se le app legacy si riferiscono in qualche modo al finanziamento, o se sei in un settore che sottostà al GMP , ad esempio nell'industria farmaceutica)

Infine, che cosa accadrà se deciderà da solo di eliminare il codice di migrazione nonostante le ferme richieste dei tuoi sviluppatori e in seguito si scopre che è stata una cattiva idea?

Considerando il costo dello storage e i rischi sopra menzionati, suggerirei di ascoltare i tuoi sviluppatori. Ciò non impedisce di scegliere una soluzione che soddisfi tutti, ad esempio mantenendo il codice ma spostandolo in un repository separato; dopo qualche mese potresti archiviarlo, prima di buttarlo via per sempre se gli archivi rimangono inaccessibili per molto tempo.

Non ho familiarità con VSTS in particolare, ma in github questi tipi di repository temporanei sono solitamente inseriti nel profilo personale dello sviluppatore (come miniera qui ), invece dei repository dell'organizzazione (come la mia azienda è qui ). Quindi se un progetto personale diventa un prodotto aziendale, puoi promuoverlo in seguito.

I repository personali sono altrettanto potenti di quelli dell'organizzazione. Puoi concedere ad altri sviluppatori specifici l'accesso push, accettare richieste di pull contro di esso, ecc. Gli sviluppatori possono crearli senza autorizzazione e possono mantenerli il più a lungo o il meno possibile, senza inquinare l'elenco dei repository dell'organizzazione.

Dato che i tuoi repository sono già stati promossi nell'area dell'organizzazione, vorrei dire ai tuoi sviluppatori che hanno una settimana da inserire nel loro profilo personale prima che venga cancellato. Quindi la decisione di decidere se e quanto a lungo mantenerla è decentrata.