Come posso aggiornare in modo indolore il codebase del mio team a Visual Studio 2017?

Per semplificare il tuo compito, devi garantire due cose:

1. Il progetto viene compilato e funziona correttamente in VS2017.
2. Scrivi una procedura per l'aggiornamento a VS2017 in preferibilmente i passaggi che potrebbero essere seguiti da qualsiasi tuo collega (sia in semplicità che in risorse necessarie).

Il punto 1 è abbastanza semplice e ciò che richiederà il maggior "lavoro". Idealmente si dovrebbe creare un ramo in modo da poter ancora commettere senza creare problemi per gli altri. Tieni traccia delle modifiche apportate al progetto che non possono essere risolte semplicemente aggiornando il codice da git in quanto sarà utile in seguito.

Verifica che funzioni e forse anche che sia approvato dal tuo capo (niente di peggio che scoprire in seguito che hai creato problemi perché alcuni aspetti del programma erano trascurati). Ok, a questo punto, sei pronto per il passaggio n. 2.

Il punto 2 è molto più sottile ma ugualmente importante. Non è sufficiente che funzioni per tu . Deve funzionare per tutti, e averlo per te non è una garanzia. Pertanto, dovresti scrivere una procedura per l'aggiornamento utilizzando le informazioni che hai appreso durante gli aggiornamenti di tutti i passaggi aggiuntivi che dovevi eseguire oltre alle modifiche al codice.

Una volta che hai la procedura e sei sicuro di ciò, elimina , sì, elimina il tuo progetto e inizia fresco con la versione che i tuoi compagni utilizzano dal trunk . Seguire la propria procedura per arrivare al punto B sul ramo (modificando la procedura solo per compensare il fatto che il codice è ancora sul ramo e non nel bagagliaio). Tutto dovrebbe funzionare come previsto, e fino a quando non sarà così, avrai del lavoro da fare fino a quando i problemi non saranno risolti o la procedura verrà modificata.

Solo ora puoi trasferire le modifiche al trunk. Assicurati che i tuoi colleghi conoscano la data. Idealmente si otterrebbe l'opportunità di eseguire un ultimo controllo usando la propria procedura per assicurarsi che tutto funzioni come previsto.

Potrebbe essere un'opzione percorribile separare un "master legacy" in git per quelli che ancora usano il 2013. Questo è particolarmente positivo poiché sai che il ramo alla fine verrà chiuso, poiché tutti si sono trasferiti al 2017 (git sempre vivo i rami non sono una buona cosa).

In questo modo puoi concentrarti sul ramo principale per qualsiasi nuovo lavoro utilizzando il 2017, ma chiunque sia ancora nel mezzo del lavoro può rimanere sul ramo legacy e le sue modifiche vengono unite / selezionate per essere gestite. Questo naturalmente richiede anche il backporting dei cambiamenti da master a legacy, quindi hai un incentivo per la transizione il più rapidamente possibile.

Nel nostro sito, manteniamo una serie di progetti su VS2010 e VS2015 (contemporaneamente). Funziona bene, ovviamente devi raddoppiare le cose e assicurarti che il compilatore VS2010 non tossi sui costrutti C ++ più recenti, ma finora funziona.

• Prima di poter avviare tutte le modifiche del 2017, ogni sviluppatore dovrebbe avere installato VS2017. Probabilmente lo fai all'inizio, quindi qualsiasi incompatibilità tra avere VS2013 e VS2017 installati fianco a fianco può essere risolta man mano che vai avanti. (Non me ne aspetto molti.)
• La cosa migliore sarebbe iniziare con alcuni rifrattori per il 2013 per rendere le cose senza problemi in seguito:
  • Dovresti mettere tutte le dipendenze precompilate (di terze parti) in una cartella separata che denota il set di strumenti VS (ad esempio 3rdPartyResourcerdPartyLib1\bin\vc120\lalala.lib )
  • Le cartelle di output di terze parti e in particolare le cartelle intermedie dovrebbero includere il set di strumenti della piattaforma, in modo da poter compilare successivamente VS2013 e VS2017 fianco a fianco per una transizione fluida. (Le cartelle di output finali delle tue app non ne hanno davvero bisogno.)
  • Assicurati che le tue impostazioni di vcxproj vengano tutte pulite e allineate tra le piattaforme e le impostazioni di debug / release. È possibile spostare le impostazioni comuni in .props file.

Almeno per noi con VS2010 rispetto a VS2015, possiamo facilmente condividere file vcxproj - hanno bisogno solo di alcune modifiche per costruire su entrambi. Abbiamo alcune semplici personalizzazioni manuali nei file per farlo funzionare bene per noi, ad esempio:

bla.vcxproj -

...
<PropertyGroup Condition="'$(VisualStudioVersion)' == '10.0'">
    <OurPlatformToolset>v100</OurPlatformToolset>
</PropertyGroup>
<PropertyGroup Condition="'$(VisualStudioVersion)' == '14.0'">
    <OurPlatformToolset>v140</OurPlatformToolset>
</PropertyGroup>
<!-- Override hardcoded setting PlatformToolset with our version detected from VS -->
<PropertyGroup Label="Configuration">
  <PlatformToolset>$(OurPlatformToolset)</PlatformToolset>
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />

Tutto sommato, alcuni macro vanno molto lontano per rendere i file compatibili con vcxproj tra le versioni di studio - e questo è necessario solo se devi usarli fianco a fianco per un periodo di tempo. In caso contrario, fare le modifiche su un ramo separato e unirle nuovamente quando si desidera eseguire la transizione potrebbe essere comunque un'idea migliore.