PowerShellGallery publiceren richtlijnen en aanbevolen proceduresPowerShellGallery Publishing Guidelines and Best Practices

Dit onderwerp beschrijft aanbevolen stappen die worden gebruikt door de Microsoft-teams zodat de items die zijn gepubliceerd naar de PowerShell-galerie algemeen wordt vastgesteld en hoge waarde bieden aan gebruikers, op basis van hoe de PowerShell-galerie manifest gegevens verwerkt en feedback van grote aantallen gebruikers van de PowerShell-galerie.This topic describes recommended steps used by Microsoft teams to ensure the items published to the PowerShell Gallery will be widely adopted and provide high value to users, based on how the PowerShell Gallery handles manifest data and on feedback from large numbers of PowerShell Gallery users. Items die zijn gepubliceerd in deze richtlijnen wordt vaker worden geïnstalleerd, wordt vertrouwd, en trekt meer gebruikers.Items that are published following these guidelines will be more likely to be installed, trusted, and attract more users.

Hieronder volgen richtlijnen voor wat een goede PowerShell-galerie-item, welke optionele Manifest instellingen zijn zeer belangrijk uw code met feedback van de eerste revisoren verbetering maakt en Powershell Script Analyzer, versiebeheer de module, documentatie, tests en voorbeelden voor het gebruik van wat u hebt gedeeld.Included below are guidelines for what makes a good PowerShell Gallery item, what optional Manifest settings are most important, improving your code with feedback from initial reviewers and Powershell Script Analyzer, versioning your module, documentation, tests & examples for how to use what you have shared. Veel van deze documentatie volgt de richtlijnen voor publicatie Resource Modules van hoge kwaliteit DSC.Much of this documentation follows the guidelines for publishing High Quality DSC Resource Modules.

Zie voor het mechanisme van een item publiceren naar de PowerShell-galerie, maken en publiceren van een Item.For the mechanics of publishing an item to the PowerShell Gallery, see Creating and Publishing an Item.

Feedback over deze richtlijnen wordt verwelkomde.Feedback on these guidelines is welcomed. Als u feedback hebt, opent u problemen in onze Github-opslagplaats voor documentatie.If you do have feedback, please open issues in our Github documentation repository.

Aanbevolen procedures voor het publiceren van itemsBest practices for publishing items

De volgende best practices zijn wat de gebruikers van de PowerShell-galerie-items zeggen is belangrijk en staan in volgorde van prioriteit nominaal.The following best practices are what the users of PowerShell Gallery items say is important, and are listed in nominal priority order. Items die aan deze richtlijnen voldoet waarschijnlijk veel meer worden gedownload en door anderen zijn vastgesteld.Items that follow these guidelines are far more likely to be downloaded and adopted by others.

  • Gebruik PSScriptAnalyzerUse PSScriptAnalyzer
  • Documentatie en voorbeelden opnemenInclude documentation and examples
  • Reageren op feedback wordenBe responsive to feedback
  • Modules in plaats van scripts opgevenProvide modules rather than scripts
  • Bevatten koppelingen naar een siteProvide links to a project site
  • Tests met uw modules bevattenInclude tests with your modules
  • Opnemen en/of de koppeling licentievoorwaardenInclude and/or link to license terms
  • Meld u aan uw codeSign your code
  • Ga als volgt SemVer richtlijnen voor het versiebeheerFollow SemVer guidelines for versioning
  • Gebruik van veelgebruikte tags, zoals beschreven in de galerie voor algemene PowerShell-codesUse common tags, as documented in Common PowerShell Gallery tags
  • Test publiceren met behulp van een lokale opslagplaatsTest publishing using a local repository

Elk van deze wordt kort beschreven in de onderstaande secties.Each of these is covered briefly in the sections below.

Gebruik PSScriptAnalyzerUse PSScriptAnalyzer

PSScriptAnalyzer is een gratis statische code analysis-hulpprogramma dat werkt met PowerShell-code.PSScriptAnalyzer is a free static code analysis tool that works on PowerShell code. PSScriptAnalyzer wordt de meest voorkomende problemen gezien in de PowerShell-code en vaak een aanbeveling voor het oplossen van het probleem te identificeren.PSScriptAnalyzer will identify the most common issues seen in PowerShell code, and often a recommendation for how to fix the issue. Het hulpprogramma is eenvoudig te gebruiken en de problemen als fouten categoriseert (ernstig, moeten worden opgelost), waarschuwing (moeten worden beoordeeld & moet worden opgelost), en informatie (waard voor aanbevolen procedures).The tool is easy to use, and categorizes the issues as Errors (severe, must be addressed), Warning (need to be reviewed & should be addressed), and Information (worth checking out for best practices). Alle items item gepubliceerd naar de PowerShell-galerie worden gescand met PSScriptAnalyzer en eventuele fouten wordt gemeld aan de eigenaar en moeten worden opgelost.All items item published to the PowerShell Gallery will be scanned using PSScriptAnalyzer, and any errors will be reported back to the owner and must be addressed.

De aanbevolen procedure is het uitvoeren van Invoke-ScriptAnalyzer met -Recurse en -Severity waarschuwing.The best practice is to run Invoke-ScriptAnalyzer with -Recurse and -Severity Warning.

Bekijk de resultaten en zorg ervoor dat:Review the results, and ensure that:

  • Alle fouten zijn gecorrigeerd of in de documentatie van uw verholpenAll Errors are corrected or addressed in your documentation
  • Alle waarschuwingen zijn gecontroleerd en verholpen, indien van toepassingAll Warnings are reviewed, and addressed where applicable

Gebruikers die items van de PowerShell Gallery verkrijgen wordt dringend aangeraden PSScriptAnalyzer uitvoeren en evalueren van alle fouten en waarschuwingen.Users who acquire items from the PowerShell Gallery are strongly encouraged to run PSScriptAnalyzer and evaluate all Errors and Warnings. Gebruikers worden doorgaans contact op met de eigenaren van het item als ze ziet dat er een fout gerapporteerd door PSScriptAnalyzer.Users are very likely to contact item owners if they see that there is an error reported by PSScriptAnalyzer. Als er een goede reden voor het object te houden van code die is gemarkeerd als een fout, moet u die informatie toevoegen aan de documentatie om te voorkomen dat dezelfde vraag worden beantwoord vaak.If there is a compelling reason for your item to keep code that is flagged as an error, add that information to your documentation to avoid having to answer the same question many times.

Documentatie en voorbeelden opnemenInclude documentation and examples

Documentatie en voorbeelden worden de beste manier om te controleren of gebruikers kunnen profiteren van een gedeelde-code.Documentation and examples are the best way to ensure users can take advantage of any shared code.

Documentatie is het nuttigst wat om op te nemen in gepubliceerd naar de PowerShell-galerie-items.Documentation is the most helpful thing to include in items published to the PowerShell Gallery. Gebruikers worden items zonder documentatie over het algemeen omzeilen als de alternatieve te lezen van de code om te begrijpen wat het item is en het gebruik ervan.Users will generally bypass items without documentation, as the alternative is to read the code to understand what the item is and how to use it. Er zijn verschillende artikelen beschikbaar zijn in MSDN voor het doorgeven van documentatie met PowerShell-opties, waaronder:There are several articles available in MSDN on how to provide documentation with PowerShell items, including:

  • Richtlijnen voor het ontwikkelen van help zijn Cmdlet helpen schrijvenGuidelines for providing help are in How to Write Cmdlet Help
  • Maken van de help van cmdlet, dit is de beste manier om een PowerShell-script, functie of cmdlet.Creating cmdlet help, which is the best approach for any PowerShell script, function, or cmdlet. Voor informatie over het maken van de help van cmdlet beginnen met schrijven Cmdlet helpen in de MSDN-bibliotheek.For information about how to create cmdlet help, start with How to Write Cmdlet Help in the MSDN library. Zie het Help-informatie in een script toevoegen opmerking op basis van Help over.To add help within a script, see About Comment Based Help.
  • Veel modules ook documentatie in tekstindeling zoals MarkDown-bestanden.Many modules also include documentation in text format, such as MarkDown files. Dit is vooral handig zijn wanneer er een site in Github, waar Markdown een intensief gebruikte indeling is.This can be particularly helpful when there is a project site in Github, where Markdown is a heavily used format. De aanbevolen procedure is het gebruik van Markdown met een vleugje GithubThe best practice is to use Github-flavored Markdown

Enkele voorbeelden van gebruikers hoe het item is bedoeld om te worden gebruikt.Examples show users how the item is intended to be used. Veel ontwikkelaars dicteert dat ze voorbeelden voordat documentatie om te begrijpen hoe gebruikmaken van iets bekijken.Many developers will say that they look at examples before documentation to understand how to use something. Het aanbevolen type voorbeelden tonen basisgebruik, plus een gesimuleerde realistische gebruiksvoorbeeld en de code is goed opmerkingen.The best type of examples show basic use, plus a simulated realistic use case, and the code is well-commented. Voorbeelden voor modules die zijn gepubliceerd naar de PowerShell-galerie moeten zich in een map van de voorbeelden in de hoofdmap van de module.Examples for modules published to the PowerShell Gallery should be in an Examples folder under the module root.

Een goede patroon voor voorbeelden vindt u in de PSDscResource module onder de map Examples\RegistryResource.A good pattern for examples can be found in the PSDscResource module under the Examples\RegistryResource folder. Er zijn vier voorbeeld gebruiksvoorbeelden met een korte beschrijving boven aan elk bestand dat documenten wat wordt wordt gedemonstreerd.There are four sample use cases with a brief description at the top of each file that documents what is being demonstrated.

Reageren op feedbackRespond to feedback

De waarde van item eigenaars die goed op feedback reageren wordt zeer door de community.Item owners who respond properly to feedback are highly valued by the community. Gebruikers die feedback geven feitelijke zijn belangrijk om te reageren op, zoals ze geïnteresseerd in het artikel zijn om te helpen verbeteren.Users who provide constructive feedback are important to respond to, as they are interested enough in the item to try to help improve it.

Er zijn twee methoden voor feedback beschikbaar in de galerie met PowerShell:There are two feedback methods available in the PowerShell Gallery:

  • Neem contact op met de eigenaar: Dit kan een gebruiker een e-mailbericht verzenden naar de eigenaar van het item.Contact Owner: This allows a user to send an email to the item owner(s). Als de eigenaar van een item, is het belangrijk om te controleren van het e-mailadres gebruikt met de PowerShell-galerie-items en reageren op problemen die worden gegenereerd.As an item owner, is important to monitor the email address used with the PowerShell Gallery items, and respond to issues that are raised. Een nadeel van deze methode is dat alleen de gebruiker en de eigenaar ooit de communicatie, ziet zodat de eigenaar hebben kan om deze vraag te beantwoorden vaak.The one disadvantage to this method is that only the user and owner will ever see the communication, so the owner may have to answer the same question many times.
  • Opmerkingen: Is een opmerkingenveld onder aan de pagina item.Comments: At the bottom of the item page is a Comment field. Het voordeel van dit systeem is dat andere gebruikers kunnen zien de opmerkingen en reacties, waardoor het aantal keren dat een enkele vraag moet worden beantwoord.The advantage to this system is that other users can see the comments and responses, which reduces the number of times any single question must be answered. Als de eigenaar van een item wordt aanbevolen dat u de opmerkingen voor elk item volgt.As an item owner, it is strongly recommended that you Follow the comments made for each item. Zie Feedback geven via sociale Media of opmerkingen voor meer informatie over hoe u dat doet.See Providing Feedback via Social Media or Comments for details on how to do that.

Zijn eigenaars die constructively op feedback reageren op prijs gesteld door de community.Owners who respond to feedback constructively are appreciated by the community. De mogelijkheid gebruik in het rapport voor het aanvragen van meer informatie, indien nodig, bieden een tijdelijke oplossing of identificeren als een update wordt een probleem opgelost.Use the opportunity in the report to request more information if needed, provide a workaround, or identify if an update fixes a problem.

Als er ongeschikte gedrag van een van deze communicatiekanalen in acht genomen, moet u de functie rapport misbruik van de PowerShell-galerie gebruiken om het contact opnemen met de beheerders-galerie.If there is inappropriate behavior observed from either of these communication channels, use the Report Abuse feature of the PowerShell Gallery to contact the Gallery Administrators.

Modules Versus ScriptsModules Versus Scripts

Een script te delen met andere gebruikers is een goede en biedt andere voorbeelden van hoe ze hebben wellicht problemen op te lossen.Sharing a script with other users is great, and provides others with examples of how to solve problems they may have. Het probleem is dat de scripts in de PowerShell-galerie één bestanden zonder afzonderlijke documentatie, voorbeelden en tests.The issue is that scripts in the PowerShell Gallery are single files without separate documentation, examples, and tests.

PowerShell-Modules hebben een mapstructuur waarmee meerdere mappen en bestanden die moeten worden opgenomen in het pakket.PowerShell Modules have a folder structure that allows multiple folders and files to be included with the package. Structuur van de module kunt u met inbegrip van de andere items die wij in de lijst als best practices: cmdlet help, documentatie, voorbeelden en tests.The module structure enables including the other items we list as best practices: cmdlet help, documentation, examples, and tests. Het grootste nadeel is dat een script in een module moet worden weergegeven en als een functie gebruikt.The biggest disadvantage is that a script inside a module must be exposed and used as a function. Zie voor meer informatie over het maken van een module een Windows PowerShell-Module schrijven.For information on how to create a module, see Writing a Windows PowerShell Module.

Zijn er situaties waarin een script zorgt voor een betere ervaring voor de gebruiker, met name met DSC-configuraties.There are situations where a script provides a better experience for the user, particularly with DSC configurations. Er is de aanbevolen procedure voor DSC-configuraties voor het publiceren van de configuratie als een script met een bijbehorende module met de documenten, voorbeelden en tests.The best practice for DSC configurations is to publish the configuration as a script with an accompanying module that contains the docs, examples, and tests. Het script geeft een lijst van de bijbehorende module met behulp van RequiredModules = @(naam van de Module).The script lists the accompanying module using RequiredModules = @(Name of the Module). Deze methode kan worden gebruikt bij elk script.This approach can be used with any script.

Zelfstandige scripts die Volg de aanbevolen procedures bieden de feitelijke waarde aan andere gebruikers.Standalone scripts that follow the other best practices provide real value to other users. Mits documentatie op basis van een opmerking en een koppeling naar een Site nadrukkelijk aanbevolen zijn bij het publiceren van een script naar de PowerShell-galerie.Providing comment-based documentation and a link to a Project Site are highly recommended when publishing a script to the PowerShell Gallery.

Een Site-Project is waar een uitgever kan communiceren rechtstreeks met de gebruikers van de PowerShell-galerie-items.A Project Site is where a publisher can interact directly with the users of their PowerShell Gallery items. Gebruikers liever items die deze, omdat deze hiermee de mogelijkheid voor informatie over het item eenvoudiger.Users prefer items that provide this, as it allows them to get information about the item more easily. Aantal items in de PowerShell-galerie in GitHub worden ontwikkeld, worden andere geleverd door organisaties met een speciale website.Many items in the PowerShell Gallery are developed in GitHub, others are provided by organizations with a dedicated web presence. Elk van deze worden site voor een beschouwd.Each of these can be considered a project site.

Een koppeling toe te voegen, wordt dit gedaan door ProjectURI als volgt in de sectie PSData van het manifest, waaronder:Adding a link is done by including ProjectURI in the PSData section of the manifest as follows:

    # A URL to the main website for this project.
    ProjectUri = 'https://github.com/powershell/powershell'

Wanneer een ProjectURI is opgegeven, wordt de PowerShell-galerie bevat een koppeling naar de Site van het Project aan de linkerkant van de pagina item.When a ProjectURI is provided, the PowerShell Gallery will include a link to the Project Site on the left side of the item page.

Tests opnemenInclude tests

Het is belangrijk dat gebruikers, met inbegrip van tests met open source code als u deze zekerheid krijgt over wat u valideren en bevat informatie over de werking van uw code.Including tests with open-source code is important to users, as it gives them assurance about what you validate, and provides information on how your code works. Ook kunnen gebruikers zodat ze niet de functionaliteit van uw oorspronkelijke opsplitsen als ze de code aanpassen aan hun omgeving aanpassen.It also allows users to ensure they do not break your original functionality if they modify your code to fit their environment.

Het is raadzaam dat de tests worden geschreven om te profiteren van het kader van de test Pester, waarbij heeft is speciaal ontworpen voor PowerShell.It is strongly recommended that tests be written to take advantage of the Pester test framework, which has been designed specifically for PowerShell. Lastige is beschikbaar in GitHub, wordt de PowerShell Gallery, en wordt in Windows 10, Windows Server 2016, WMF 5.0 en WMF 5.1 wordt geleverd.Pester is available in GitHub, the PowerShell Gallery, and ships in Windows 10, Windows Server 2016, WMF 5.0 and WMF 5.1.

De Pester project-site in GitHub omvat goede documentatie over het schrijven van Pester tests uit aan de slag aan aanbevolen procedures.The Pester project site in GitHub includes good documentation on writing Pester tests, from getting started to best practices.

De doelen voor de dekking van de test worden specifiek genoemd de Bronmodule van hoge kwaliteit documentatie, testen met 70% eenheid code dekking aanbevolen.The targets for test coverage are called out in the High Quality Resource Module documentation, with 70% unit test code coverage recommended.

Alle items die zijn gepubliceerd naar de PowerShell-galerie moet de licentievoorwaarden opgeven of gebonden aan de licentie die is opgenomen in de gebruiksvoorwaarden onder "Vertonen A".All items published to the PowerShell Gallery must specify the license terms, or be bound by the license included in the Terms of Use under "Exhibit A". De aanbevolen aanpak voor het opgeven van een andere licentie wordt een koppeling naar de licentie die met behulp van de LicenseURI in PSData.The best approach to specifying a different license is to provide a link to the license using the LicenseURI in PSData. In het Manifest velden aanbevolen-onderwerp vindt u een voorbeeld.You can find an example in the Recommended Manifest Fields topic.

PrivateData = @{
    PSData = @{

        # Tags applied to this module. These help with module discovery in online galleries.
        Tags = @('.net','acl','active-directory')

        # A URL to the license for this module.
        LicenseUri = 'http://www.apache.org/licenses/LICENSE-2.0'

Meld u aan uw codeSign your code

Ondertekening van programmacode voorziet gebruikers van het hoogste niveau van zekerheid voor wie het item heeft uitgegeven, en dat de kopie van de code ze verkrijgen is precies wat de uitgever uitgebracht.Code signing provides users with the highest level of assurance for who published the item, and that the copy of the code they acquire is exactly what the publisher released. Zie voor meer informatie over het algemeen voor ondertekening van programmacode, Inleiding tot de ondertekening van programmacode.To learn more about code signing generally, see Introduction to Code Signing. PowerShell ondersteunt validatie van via twee primaire benaderingen voor ondertekening van programmacode:PowerShell supports validation of code signing through two primary approaches:

  • Ondertekening scriptbestandenSigning script files
  • Een module voor het ondertekenen van catalogusCatalog signing a module

Ondertekening van bestanden met PowerShell is een goed tot stand gebrachte aanpak om ervoor te zorgen dat de code wordt uitgevoerd is geproduceerd door een betrouwbare bron en is niet gewijzigd.Signing PowerShell files is a well-established approach to ensuring that the code being executed was produced by a reliable source, and has not been modified. Meer informatie over het ondertekenen van PowerShell-scriptbestanden wordt beschreven in de over ondertekening onderwerp.Details on how to sign PowerShell script files is covered in the About Signing topic. Bij overzicht kan een handtekening worden toegevoegd aan een. Ps1-bestand dat PowerShell valideert wanneer het script wordt geladen.In overview, a signature can be added to any .PS1 file that PowerShell validates when the script is loaded. PowerShell worden beperkt met behulp van de uitvoeringsbeleid -cmdlets voor het gebruik van ondertekende scripts.PowerShell can be constrained using the Execution Policy cmdlets to ensure use of signed scripts.

Catalogus modules ondertekening is een functie die is toegevoegd aan PowerShell in versie 5.1.Catalog signing modules is a feature added to PowerShell in version 5.1. Het ondertekenen van een module wordt beschreven in de catalogus Cmdlets onderwerp.How to sign a module is covered in the Catalog Cmdlets topic. Bij overzicht wordt ondertekening van de catalogus gedaan door het maken van een catalogusbestand waarin een hash-waarde voor elk bestand in de module, en vervolgens ondertekent dat bestand.In overview, catalog signing is done by creating a catalog file, which contains a hash value for every file in the module, and then signing that file. De PowerShellGet publiceren-module, installatie-module opslaan-module en update-module-cmdlets wordt controleren van de handtekening om ervoor te zorgen dat geldig is en bevestig vervolgens de hash-waarde voor elk item overeenkomt met wat is er in de catalogus.The PowerShellGet publish-module, install-module, save-module, and update-module cmdlets will check the signature to ensure it is valid, then confirm that the hash value for each item matches what is in the catalog. Als een eerdere versie van de module is geïnstalleerd op het systeem, bevestigt installatie-module dat de instantie voor het ondertekenen van voor de nieuwe versie overeenkomt met wat eerder is geïnstalleerd.If a previous version of the module is installed on the system, install-module will confirm that the signing authority for the new version matches what was previously installed. Catalogus ondertekening werkt met, maar er is geen vervanging voor ondertekening scriptbestanden.Catalog signing works with, but does not replace signing script files. PowerShell worden handtekeningen van de catalogus niet gevalideerd tijdens het laden van een module.PowerShell does not validate catalog signatures at module load time.

Volg de richtlijnen SemVer voor versiebeheerFollow SemVer guidelines for versioning

SemVer is een openbare conventie die wordt beschreven hoe u de structuur en wijzigt u een versie zodat u eenvoudig intepretation van wijzigingen.SemVer is a public convention that describes how to structure and change a version to allow easy intepretation of changes. De versie voor het object moet zijn opgenomen in de manifest-gegevens.The version for your item must be included in the manifest data.

  • De versie moet worden gestructureerd als 3 numerieke blokken gescheiden door punten, zoals in 0.1.1 of 4.11.192The version should be structured as 3 numeric blocks separated by periods, as in 0.1.1 or 4.11.192
  • Beginnen met '0' versies erop wijzen dat het item nog niet klaar productie is, en het eerste nummer alleen met '0' beginnen moet als dit het enige dat wordt gebruiktVersions starting with "0" indicate that the item is not yet production ready, and the first number should only begin with "0" if that is the only number used
  • Wijzigingen in het eerste nummer (1.9.9999-2.0.0) geven aan de primaire en breken wijzigingen tussen de versiesChanges in the first number (1.9.9999 to 2.0.0) indicate major and breaking changes between the versions
  • Wijzigingen in het tweede getal (1.01-1,02) geven functieniveau wijzigingen, zoals het toevoegen van nieuwe cmdlets naar een moduleChanges to the second number (1.01 to 1.02) indicate feature-level changes, such as adding new cmdlets to a module
  • Wijzigingen in het derde getal geven vaste wijzigingen, zoals nieuwe parameters, bijgewerkte voorbeelden of nieuwe testsChanges to the third number indicate non-breaking changes, such as new parameters, updated samples, or new tests
  • Bij het weergeven van versies worden PowerShell de versies gesorteerd als tekenreeksen, dus 1.01.0 wordt beschouwd als groter is dan 1.001.0When listing versions, PowerShell will sort the versions as strings, so 1.01.0 will be treated as greater than 1.001.0

PowerShell is gemaakt voordat SemVer is gepubliceerd, dus deze ondersteuning voor de meeste, maar niet alle elementen van SemVer, speciaal biedt:PowerShell was created before SemVer was published, so it provides support for most but not all elements of SemVer, specifically:

  • Prerelease tekenreeksen worden niet ondersteund in versienummers.It does not support prerelease strings in version numbers. Dit is handig wanneer een uitgever wil een preview-versie van een nieuwe primaire versie na het opgeven van een versie 1.0.0 leveren.This is useful when a publisher wishes to deliver a preview release of a new major version after providing a version 1.0.0. Dit wordt ondersteund in een toekomstige versie van de PowerShell-galerie en PowerShellGet-cmdlets.This will be supported in a future release of the PowerShell Gallery and PowerShellGet cmdlets.
  • Toestaan dat versietekenreeksen met 1, 2 en 4 segmenten PowerShell en de PowerShell-galerie.PowerShell and the PowerShell Gallery allow version strings with 1, 2, and 4 segments. Veel vroege modules niet de richtlijnen hebt gevolgd en versies van het product van Microsoft build informatie zoals een 4th blokkeren van de getallen (bijvoorbeeld 5.1.14393.1066) bevatten.Many early modules did not follow the guidelines, and product releases from Microsoft include build information as a 4th block of numbers (for example 5.1.14393.1066). Een verwerkt versioning worden deze verschillen genegeerd.From a versioning standpoint, these differences are ignored.

Testen met behulp van een lokale opslagplaatsTest using a local repository

De PowerShell-galerie, is niet ontworpen om te worden van een doel voor het testen van het publicatieproces.The PowerShell Gallery is not designed to be a target for testing the publishing process. De beste manier om het testen van het end-to-end-proces van publiceren naar de PowerShell-galerie is het instellen en gebruiken van uw eigen lokale opslagplaats.The best way to test out the end-to-end process of publishing to the PowerShell Gallery is to set up and use your own local repository. Dit kan gebeuren in een aantal manieren, met inbegrip van:This can be done in a few ways, including:

  • Een lokaal exemplaar van de PowerShell Gallery instellen met behulp van de PS persoonlijke galerie project in Github.Set up a local PowerShell Gallery instance, using the PS Private Gallery project in Github. Deze preview-project kunt u een exemplaar van de PowerShell-galerie die u kunt beheren en deze gebruiken voor uw tests instellen.This preview project will help you set up an instance of the PowerShell Gallery that you can control, and use for your tests.
  • Instellen van een interne Nuget-opslagplaats.Set up an internal Nuget repository. Dit is vereist meer werk om in te stellen, maar heeft het voordeel van het valideren van een paar meer van de vereisten, met name valideren gebruik van een API-sleutel en het al dan niet afhankelijkheden aanwezig zijn in de doel-wanneer u publiceert.This will require more work to set up, but will have the advantage of validating a few more of the requirements, notably validating use of an API key, and whether or not dependencies are present in the target when you publish.
  • Een bestandsshare instellen als de test 'opslagplaats'.Set up a file share as the test “repository”. Dit is eenvoudig te installeren, maar omdat het een bestandsshare, de hierboven beschreven validaties zal niet plaatsvinden.This is easy to set up, but since it is a file share, the validations noted above will not take place. Een van de mogelijke voordelen is in dit geval dat de bestandsshare wordt niet gecontroleerd voor de API-sleutel (vereist), zodat u kunt dezelfde sleutel u zou doen om te publiceren naar de PowerShell-galerie.One potential advantage in this case is that the file share does not check the (required) API key, so you can use the same key you would to publish to the PowerShell Gallery.

Met elk van deze oplossingen kunt registreren PSRepository te gebruiken voor het definiëren van een nieuwe 'opslagplaats', waarmee u in de - eigenschap van de opslagplaats voor publiceren-Module.With any of these solutions, use Register-PSRepository to define a new "repository", which you use in the -Repository property for Publish-Module.

Een extra contactpunt over test publiceren: een u naar de PowerShell-galerie publiceren-item kan niet worden verwijderd zonder hulp van het operationele team, die wordt bevestigd dat er is niets is afhankelijk van het item dat u wilt publiceren.One additional point about test publishing: any item you publish to the PowerShell Gallery cannot be deleted without help from the operations team, who will confirm that nothing is dependent upon the item you wish to publish. Om die reden we bieden geen ondersteuning voor de PowerShell-galerie als doel testen en neemt contact met een willekeurige uitgever die doet.For that reason, we do not support the PowerShell Gallery as a testing target, and will contact any publisher who does so.

De meest succesvolle aanpak die we hebben gevonden voor gepubliceerd naar de PowerShell-galerie-items is als volgt:The most successful approach we have found for items published to the PowerShell Gallery is this:

  • Eerste-ontwikkeling in een een open source-project-site.Do initial development in a an open-source project site. Het PowerShell-Team gebruik maakt van Github.The PowerShell Team uses Github.
  • Gebruik van feedback van de revisoren en Powershell Script Analyzer ophalen van de code naar een stabiele statusUse feedback from reviewers and Powershell Script Analyzer to get the code to stable state
  • Documentatie, bevatten zodat anderen weten hoe u uw werk gebruiktInclude documentation, so others know how to use your work
  • Test de publishing uitgevoerd met behulp van een lokale opslagplaats.Test out the publishing action using a local repository.
  • Een stabiele of alfa-release publiceren naar de PowerShell-galerie, zorg ervoor dat u de documentatie en een koppeling naar de projectsite van uwPublish a stable or Alpha release to the PowerShell Gallery, making sure to include the documentation and link to your project site
  • Feedback verzamelen en stabiele updates publiceren naar de PowerShell-galerie herhalen op de code in uw projectsiteGather feedback and iterate on the code in your project site, then publish stable updates to the PowerShell Gallery
  • Voorbeelden en Pester tests in uw project en uw module toevoegenAdd examples and Pester tests in your project and your module
  • Bepalen of u code wilt ondertekenen van uw itemDecide if you want to code sign your item
  • Als u denkt het project is klaar dat voor gebruik in een productieomgeving, een 1.0.0 publiceert de versie van de PowerShell-galerieWhen you feel the project is ready to use in a production environment, publish a 1.0.0 version to the PowerShell Gallery
  • Blijven feedback verzamelen en uw code op basis van gebruikersinvoer herhalenContinue to gather feedback and iterate on your code based on user input