Sessione dell'evento DevOps@Work 2019 sulla migrazione da Team Foundation Server ad Azure DevOps Services in modo granulare - ossia senza utilizzare il servizio di importazione diretta della collection da parte di Microsoft. Copre Build e Release Definition, Work Item e codice sorgente (Git e TFVC).
Strategie di migrazione da Team Foundation Server ad Azure DevOps Services
1. STRATEGIE DI MIGRAZIONE DA TFS AD
AZURE DEVOPS SERVICES
Matteo Emili
matteo.emili@live.com||https://mattvsts.blogspot.com||https://twitter.com/MattVSTS
2.
3. DEVOPS
AT WORK
DI COSA PARLIAMO?
Abbiamo una istanza di Team Foundation Server in uso da
diversi anni, e finalmente abbiamo luce verde per migrare
ad Azure DevOps Services. E adesso come faccio?
3
4. DEVOPS
AT WORK
LAVIA PIÚ SEMPLICE
Microsoft mette a disposizione un servizio di importazione dell’intera istanza
di Team Foundation Server verso Azure DevOps Services
Supporta lo scenario di completa ad altissima fedeltá
Ci sono alcuni limiti tecnici e pratici, potrebbe essere necessaria
una migrazione granulare e selettiva
https://docs.microsoft.com/en-us/azure/devops/articles/migration-import
4
5. DEVOPS
AT WORK
LAVIA MENO SEMPLICE
Situazioni in cui non possiamo effettuare un lift-and-shift di
Team Foundation Server nel cloud
Si deve migrare con approccio mirato e strumenti dedicati
Non esiste una soluzione standard, ma una serie di pratiche note
5
8. DEVOPS
AT WORK
MIGRARE BUILD E RELEASE
8
É la parte piú semplice da eseguire!
Basta esportare le definizioni e re-importarle a
destinazione, sostituendo parametri di progetto
Ottima scusa per tenere traccia delle definizioni,
inserendole nel repository del codice sorgente
Build and Release
9. DEVOPS
AT WORK
MIGRARE BUILD E RELEASE
9
Facile, basta esportare le definizioni e re-
importarle a destinazione, sostituendo parametri
Build and Release
12. DEVOPS
AT WORK
MIGRARE GITAGIT
12
Sul serio?!
git clone --mirror https://tfs.acme.corp/Department/Project
cd Project
git push --mirror https://dev.azure.com/project
Ci possono essere delle varianti di questo approccio – con remote, utente esplicito, etc.
Source Code
13. DEVOPS
AT WORK
MIGRARE GITAGIT
13
Migrazione di solo codice
git clone https://tfs.acme.corp/Department/Project
cd Project
git remote add target https://dev.azure.com/project
git push --u target master
Source Code
19. DEVOPS
AT WORK
MIGRARE WORK ITEM
19
La maggior parte del tempo viene speso in questa attivitá
É considerato essenziale per il valore della storia
Spesso questo valore viene sovrastimato (ci servono revisioni vecchie di anni?)
Work Items
20. DEVOPS
AT WORK
IL VALORE DELLE REVISIONI STORICHE
20
Ha senso portare anni di storia in un nuovo sistema?
Possiamo consolidare la storia del Work Item
La migrazione diventa piú rapida e snella
Work Items
21. DEVOPS
AT WORK
ESSENZIALE: L’INTEGRITÁ DELL’INFORMAZIONE
21
I Work Item devono rimanere il piú fedeli possibili all’originale
Non c’é valore nell’avere delle copie malformate in un nuovo sistema
La soluzione migliore é migrare tutto quello di attivo
Ció che é considerato chiuso/risolto/eliminato rimane nel sistema legacy
Viene stabilito un collegamento fra il vecchio sistema ed il nuovo
Il sistema legacy viene mantenuto operativo in sola lettura
Work Items
23. DEVOPS
AT WORK
RECAP: AZURE DEVOPS MIGRATION TOOLS
23
Potentissimo strumento per manipolazione e migrazione di Work Item
Modifiche di massa
Migrazione ad alta fedeltá
Gestisce anche Work Item di Test Management
Permette il cambio di Process Template
https://github.com/nkdAgility/azure-devops-migration-tools
Work Items
24. DEVOPS
AT WORK
IN SOSTANZA
24
Una migrazione granulare é un progetto intenso e potenzialmente lungo
Si é sempre soggetti a limitazioni ambientali (throttling o hardware)
Ottenere alta fedeltá é abbastanza difficile, ma non impossibile
Se possibile, importate l’intera collection
Work ItemsSource Code Build and Release