Publikování na kanály NuGet (YAML/Classic)Publish to NuGet feeds (YAML/Classic)

Azure Pipelines | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 | TFS 2017Azure Pipelines | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 | TFS 2017

Poznámka

V Microsoft Team Foundation Server (TFS) 2018 a předchozích verzích se kanály sestavení a vydání nazývají definice, spuštění se nazývají sestavení, připojení služby se nazývají koncové body služby, fáze se nazývají prostředí a úlohy se nazývají fáze.In Microsoft Team Foundation Server (TFS) 2018 and previous versions, build and release pipelines are called definitions, runs are called builds, service connections are called service endpoints, stages are called environments, and jobs are called phases.

Balíčky NuGet můžete publikovat ze svého sestavení do kanálů NuGet pomocí úloh kanálu a také z klasického uživatelského rozhraní.You can publish NuGet packages from your build to NuGet feeds using the Pipeline tasks as well as the Classic user interface. Tyto balíčky můžete publikovat do:You can publish these packages to:

  • Azure Artifacts nebo služba TFS Správa balíčků.Azure Artifacts or the TFS Package Management service.
  • Další služby NuGet, například NuGet.org.Other NuGet services such as NuGet.org.
  • Vaše interní úložiště NuGet.Your internal NuGet repository.

Vytvoření balíčku NuGetCreate a NuGet package

Existují různé způsoby, jak vytvořit balíčky NuGet během sestavení.There are various ways to create NuGet packages during a build. Pokud už používáte MSBuild nebo nějaký jiný úkol k vytváření balíčků, přeskočte tuto část a publikujte balíčky.If you're already using MSBuild or some other task to create your packages, skip this section and publish your packages. V opačném případě přidejte úlohu NuGet:Otherwise, add a NuGet task:

Chcete-li vytvořit balíček, přidejte následující fragment kódu do souboru Azure-Pipelines. yml.To create a package, add the following snippet to your azure-pipelines.yml file.

- task: NuGetCommand@2
  inputs:
    command: pack
    packagesToPack: '**/*.csproj'

Úloha NuGet podporuje několik možností.The NuGet task supports a number of options. Některé z těchto klíčů jsou popsány v následujícím seznamu.The following list describes some of the key ones. Zbývající část obsahuje dokumentaci k úloze .The task documentation describes the rest.

  • packagesToPack: cesta k souborům, které popisují balíček, který chcete vytvořit.packagesToPack: The path to the files that describe the package you want to create. Pokud je nemáte, přečtěte si v dokumentaci k NuGet , kde můžete začít.If you don't have these, see the NuGet documentation to get started.
  • Konfigurace: výchozí hodnota je, $(BuildConfiguration) Pokud nechcete vždy sestavit Debug balíčky nebo nebo Release Pokud nemáte vlastní konfiguraci sestavení.configuration: The default is $(BuildConfiguration) unless you want to always build either Debug or Release packages, or unless you have a custom build configuration.
  • packDestination: výchozí hodnota je $(Build.ArtifactStagingDirectory) .packDestination: The default is $(Build.ArtifactStagingDirectory). Pokud nastavíte tuto možnost, poznamenejte si umístění, abyste ho mohli použít v úloze publikování.If you set this, make a note of the location so you can use it in the publish task.

YAML není v TFS podporován.YAML is not supported in TFS.

Správa verzí balíčkůPackage versioning

V NuGet se konkrétní balíček identifikuje podle názvu a čísla verze.In NuGet, a particular package is identified by its name and version number. Doporučený postup pro balíčky verzí je použití sémantických verzí.A recommended approach to versioning packages is to use Semantic Versioning. Čísla sémantických verzí mají tři číselné komponenty, Major.Minor.Patch .Semantic version numbers have three numeric components, Major.Minor.Patch.

Když opravíte chybu, zvýšíte tuto opravu ( 1.0.0 na 1.0.1 ).When you fix a bug, you increment the patch (1.0.0 to 1.0.1). Když uvolníte novou zpětně kompatibilní funkci, zvýšíte dílčí verzi a resetujete verzi opravy na 0 ( 1.4.17 do 1.5.0 ).When you release a new backward-compatible feature, you increment the minor version and reset the patch version to 0 (1.4.17 to 1.5.0). Když provedete zpětnou změnu, zvýšíte hlavní verzi a nastavíte dílčí a opravné verze na 0 ( 2.6.5 do 3.0.0 ).When you make a backward-incompatible change, you increment the major version and reset the minor and patch versions to 0 (2.6.5 to 3.0.0).

Kromě Major.Minor.Patch toho poskytuje sémantická verze označení pro předprodejní označení.In addition to Major.Minor.Patch, Semantic Versioning provides for a prerelease label. Popisky předprodejní verze představují spojovník ( - ) následovaný libovolnými písmeny a čísly, která chcete.Prerelease labels are a hyphen (-) followed by whatever letters and numbers you want. Verze 1.0.0-alpha , 1.0.0-beta a 1.0.0-foo12345 jsou všechny předprodejní verze nástroje 1.0.0 .Version 1.0.0-alpha, 1.0.0-beta, and 1.0.0-foo12345 are all prerelease versions of 1.0.0. I lepší sémantická Správa verzí určuje, že při řazení podle čísla verze se tyto předběžné verze vejdou přesně tam, kde byste očekávali: 0.99.999 < 1.0.0-alpha < 1.0.0 < 1.0.1-beta .Even better, Semantic Versioning specifies that when you sort by version number, those prerelease versions fit exactly where you'd expect: 0.99.999 < 1.0.0-alpha < 1.0.0 < 1.0.1-beta.

Když vytvoříte balíček v rámci kontinuální integrace (CI), můžete použít sémantickou správu verzí s popisky předprodejní verze.When you create a package in continuous integration (CI), you can use Semantic Versioning with prerelease labels. Pro tento účel můžete použít úlohu NuGet .You can use the NuGet task for this purpose. Podporuje následující formáty:It supports the following formats:

  • Použijte stejné schéma pro vytváření verzí pro sestavení a balíčky, pokud má schéma aspoň tři části oddělené tečkami.Use the same versioning scheme for your builds and packages, if that scheme has at least three parts separated by periods. Příklady schémat správy verzí, které jsou kompatibilní se systémem NuGet, jsou následující formáty kanálu sestavení:The following build pipeline formats are examples of versioning schemes that are compatible with NuGet:

    • $(Major).$(Minor).$(rev:.r), kde Major a Minor jsou dvě proměnné definované v kanálu sestavení.$(Major).$(Minor).$(rev:.r), where Major and Minor are two variables defined in the build pipeline. V tomto formátu se číslo sestavení a verze balíčku automaticky zvýší na nové číslo opravy.This format will automatically increment the build number and the package version with a new patch number. Bude uchovávat hlavní a podverze konstantní, dokud je nebudete měnit ručně v kanálu sestavení.It will keep the major and minor versions constant, until you change them manually in the build pipeline.
    • $(Major).$(Minor).$(Patch).$(date:yyyyMMdd), kde Major , Minor , a Patch jsou proměnné definované v kanálu sestavení.$(Major).$(Minor).$(Patch).$(date:yyyyMMdd), where Major, Minor, and Patch are variables defined in the build pipeline. Tento formát vytvoří nový popisek pro vydání sestavení a balíčku při zachování konstanty hlavní, vedlejší a opravné verze.This format will create a new prerelease label for the build and package while keeping the major, minor, and patch versions constant.
  • Použijte verzi, která se liší od čísla sestavení.Use a version that's different from the build number. Můžete přizpůsobit hlavní, vedlejší a opravné verze balíčků v úloze NuGet a nechat úlohu vygenerovat jedinečný popisek předprodejní na základě data a času.You can customize the major, minor, and patch versions for your packages in the NuGet task, and let the task generate a unique prerelease label based on date and time.

  • Pomocí skriptu v kanálu sestavení vygenerujte verzi.Use a script in your build pipeline to generate the version.

Tento příklad ukazuje, jak použít datum a čas jako předprodejní označení.This example shows how to use the date and time as the prerelease label.

variables:
  Major: '1'
  Minor: '0'
  Patch: '0'

steps:
- task: NuGetCommand@2
  inputs:
    command: pack
    versioningScheme: byPrereleaseNumber
    majorVersion: '$(Major)'
    minorVersion: '$(Minor)'
    patchVersion: '$(Patch)'

Seznam dalších možných hodnot pro versioningScheme najdete v tématu úloha NuGet.For a list of other possible values for versioningScheme, see the NuGet task.

YAML není v TFS podporován.YAML is not supported in TFS.

I když je sémantická Správa verzí s předprodejní štítky dobrým řešením pro balíčky vytvořené v sestaveních CI, včetně předprodejního popisku není ideální, pokud chcete uvolnit balíček pro uživatele.Although Semantic Versioning with prerelease labels is a good solution for packages produced in CI builds, including a prerelease label is not ideal when you want to release a package to your users. Problémem je to, že po vytvoření balíčků jsou neměnné.The challenge is that after packages are produced, they're immutable. Nedají se aktualizovat ani nahradit.They can't be updated or replaced.

Když vytváříte balíček v buildu, nemůžete zjistit, jestli se jedná o verzi, kterou máte v úmyslu uvolnit pro vaše uživatele, nebo jenom krok v rámci tohoto vydání.When you're producing a package in a build, you can't know whether it will be the version that you aim to release to your users or just a step along the way toward that release. Přestože žádná z následujících řešení není ideální, můžete použít jednu z těchto možností v závislosti na vaší předvolbách:Although none of the following solutions are ideal, you can use one of these depending on your preference:

  • Až ověříte balíček a rozhodnete ho uvolnit, vygenerujte jiný balíček bez označení předprodejní a publikujte ho.After you validate a package and decide to release it, produce another package without the prerelease label and publish it. Nevýhodou tohoto přístupu je, že je nutné znovu ověřit nový balíček a může odhalit nové problémy.The drawback of this approach is that you have to validate the new package again, and it might uncover new issues.

  • Publikujte jenom balíčky, které chcete uvolnit.Publish only packages that you want to release. V takovém případě nebudete používat pro každé sestavení jmenovku předprodejní verze.In this case, you won't use a prerelease label for every build. Místo toho budete znovu používat stejnou verzi balíčku pro všechny balíčky.Instead, you'll reuse the same package version for all packages. Vzhledem k tomu, že nepublikujete balíčky z každého sestavení, nebudete způsobovat konflikt.Because you do not publish packages from every build, you do not cause a conflict.

Poznámka

Všimněte si, že DotNetCore a DotNetStandard balíčky by měly být zabaleny s DotNetCoreCLI@2 úlohou, aby se zabránilo System. InvalidCastExceptions.Please note that DotNetCore and DotNetStandard packages should be packaged with the DotNetCoreCLI@2 task to avoid System.InvalidCastExceptions. Další podrobnosti najdete v úloze .NET Core CLI .See the .NET Core CLI task for more details.

task: DotNetCoreCLI@2
displayName: 'dotnet pack $(buildConfiguration)'
inputs:
    command: pack
    versioningScheme: byPrereleaseNumber
    majorVersion: '$(Major)'
    minorVersion: '$(Minor)'
    patchVersion: '$(Patch)'

Publikování balíčkůPublish your packages

V předchozí části jste zjistili, jak vytvořit balíček s každým sestavením.In the previous section, you learned how to create a package with every build. Až budete připraveni ke sdílení změn balíčku s vašimi uživateli, můžete ho publikovat.When you're ready to share the changes to your package with your users, you can publish it.

Chcete-li publikovat do Azure Artifactsho informačního kanálu, nastavte identitu sestavovací služby kolekcí projektů tak, aby byla na informačním kanálu přispěvatelem .To publish to an Azure Artifacts feed, set the Project Collection Build Service identity to be a Contributor on the feed. Další informace o oprávněních pro Správa balíčků informačních kanálů najdete v tématu zabezpečení a sdílení balíčků pomocí oprávnění informačního kanálu.To learn more about permissions to Package Management feeds, see Secure and share packages using feed permissions. Přidejte do souboru následující fragment kódu azure-pipelines.yml .Add the following snippet to your azure-pipelines.yml file.

steps:
- task: NuGetAuthenticate@0
  displayName: 'NuGet Authenticate'
- task: NuGetCommand@2
  displayName: 'NuGet push'
  inputs:
    command: push
    publishVstsFeed: '<projectName>/<feed>'
    allowPackageConflicts: true

Poznámka

Kanály artefaktů, které byly vytvořené prostřednictvím klasického uživatelského rozhraní, jsou kanály s oborem projektu.Artifact feeds that were created through the classic user interface are project scoped feeds. Do parametru musíte zahrnout název projektu publishVstsFeed : publishVstsFeed: '<projectName>/<feed>' .You must include the project name in the publishVstsFeed parameter: publishVstsFeed: '<projectName>/<feed>'. Další informace o rozdílech mezi těmito dvěma typy najdete v tématu informační kanály v oboru projektu vs. informační kanály v oboru organizace .See Project-scoped feeds vs. Organization-scoped feeds to learn about the difference between the two types.

Chcete-li publikovat do externího informačního kanálu NuGet, je nutné nejprve vytvořit připojení služby, aby odkazovalo na tento informační kanál.To publish to an external NuGet feed, you must first create a service connection to point to that feed. To můžete provést tak, že kliknete na nastavení projektu, vyberete připojení služby a pak vytvoříte nové připojení služby.You can do this by going to Project settings, selecting Service connections, and then creating a New service connection. Vyberte možnost NuGet pro připojení služby.Select the NuGet option for the service connection. Pokud se chcete připojit k informačnímu kanálu, vyplňte adresu URL kanálu a klíč rozhraní API nebo token.To connect to the feed, fill in the feed URL and the API key or token.

K publikování balíčku do informačního kanálu NuGet přidejte do souboru následující fragment kódu azure-pipelines.yml .To publish a package to a NuGet feed, add the following snippet to your azure-pipelines.yml file.

- task: NuGetAuthenticate@0
  inputs:
    nuGetServiceConnections: '<Name of the NuGet service connection>'
- task: NuGetCommand@2
  inputs:
    command: push
    nuGetFeedType: external
    versioningScheme: byEnvVar
    versionEnvVar: <VersionVariableName>

YAML není v TFS podporován.YAML is not supported in TFS.

Publikování symbolů pro balíčkyPublish symbols for your packages

Když zadáváte balíčky do Správa balíčkůho informačního kanálu, můžete také publikovat symboly.When you push packages to a Package Management feed, you can also publish symbols.

Časté otázkyFAQ

Kde se mohu dozvědět více o Azure Artifacts a službě TFS Správa balíčků?Where can I learn more about Azure Artifacts and the TFS Package Management service?

Správa balíčků v Azure Artifacts a TFSPackage Management in Azure Artifacts and TFS