Come con qualsiasi cosa, dipende. Avete considerato di utilizzare un repository di pacchetti CI separato in cui ogni commit al modulo core produce un pacchetto CI?
La più grande sfida imo è il controllo delle versioni dei pacchetti
, poiché NuGet non supporta ancora SemVer in tutta la sua estensione (ad esempio versioni di pre-release + numero di build)
.
MODIFICA: nuget.org ora supporta le versioni del pacchetto SemVer 2.0. Vedi questa specifica: https://github.com/NuGet/Home/wiki/SemVer2-support-for-nuget.org-%28server-side%29
Utilizzare correttamente SemVer. Di solito non si conosce il numero di versione rilasciato in anticipo, quindi la versione del pacchetto CI continua dall'ultima versione stabile. I pacchetti CI in quanto tali devono essere considerati pre-release.
esempio: 2.2.0-CI201209140650 (che è un accumulo CI assunto 2012/09/14 alle 06:50 per un prossimo rilascio 2.2.0) < - nota: questa versione di rilascio può ancora cambiare, ma c'è sempre sarà un percorso di aggiornamento.
Se si adotta SemVer v2.0.0, è anche possibile adottare il seguente esempio: 2.2.0-CI.2012.09.14.06.50.
Nota importante: nuget.org (e misura in cui qualsiasi altro server NuGet/servizio là fuori, come MyGet o VSTS) non supporta più versioni dei pacchetti differiscono solo per costruire i metadati!
Questo ha funzionato per me utilizzando questi vincoli (e alcune corrette configurazioni di build di TeamCity). Così, in breve, questi sono i fastidi:
- corretta versioning
- promemoria per selezionare la corretta origine del pacchetto (tenere le pkgs CI separano dalla pre-stampa e stampa, anche se tecnicamente il pacchetto C'è versione come pre-release)
- l'aggiornamento da un pacchetto di configurazione a una versione preliminare a potrebbe rappresentare un problema se il tag di rilascio preliminare è impostato su stringa superiore a "CI" (ad esempio "Alfa"). In questo caso: uninstall-package "CI" seguito dal pacchetto di installazione "Alpha".
Spero che questo aiuti!
fonte
2012-09-14 04:56:43
SourceTree rileva automaticamente che i sottomoduli contengono modifiche non impegnate e richiedono di eseguire il commit ogni volta che si impegna il progetto padre. –
Mi chiedo che fine hai fatto?Pensiamo di passare da Nuget a git submodules. Non mi piace che i nostri pacchetti nuget non contengano file pdb (per ridurre le dimensioni). Il debugging è complicato. Come sarebbe bello avere tutti i progetti in una soluzione che è possibile inserire in fase di debug. Un altro potenziale problema è una dimensione di archiviazione. Usiamo il sonatype nexus e abbiamo bisogno di avere politiche di conservazione quasi indefinite per i pacchetti, poiché alcuni pacchetti potrebbero essere richiesti se hanno 10 anni. A causa di queste dipendenze incrociate, gli archivi/pacchetti di nuget avranno dll ripetute. Paura che richiederebbe molto spazio – user1325696