VSTeam is a PowerShell module with commands for accessing your Azure DevOps Server (previously named Visual Studio Team Foundation Server) 2017/2018 and Azure DevOps (previously named Visual Studio Team Services).
The VSTeam module is also a provider allowing users to navigate their Azure DevOps Server and Azure DevOps as a file system.
To get started you can visit this blog PowerShell I would like you to meet TFS and VSTS
Documentation of the cmdlets can be found in the docs README or using Get-Help VSTeam once the module is installed.
- Windows PowerShell 5.0 or newer.
- PowerShell Core.
Install this module from the PowerShell Gallery
You can review the status of every stage of the pipeline below.
| Stage | Status |
|---|---|
| Build | |
| Linux Team Foundation Server 2017 | |
| macOS Team Foundation Server 2017 | |
| Windows Team Foundation Server 2017 | |
| Windows Team Foundation Server 2018 | |
| Windows Azure DevOps | |
| Publish to PowerShell Gallery |
The build for VSTeam is run on macOS, Linux and Windows to ensure there are no casing or other platform specific issues with the code.
On each platform unit tests are run.
During the release the module is installed on macOS, Linux and Window and tested against Azure DevOps Server and Azure DevOps before being published to the PowerShell Gallery.
In an effort to reduce the module size this repository contains two scripts Build-Module.ps1 and Merge-File.ps1 that merges similar files into a single file. The files in the formats folder are merged into vsteam.format.ps1xml. The files in the classes folder are merged into vsteam.classes.ps1. The functions from the Private and Public folders are merged into vsteam.functions.ps1. Finally all the files in the types folder are merged into vsteam.types.ps1xml. The order of the files being merged can be controlled by the _*.json files in the repository.
The JSON files must be in the following format:
{
"outputFile": "vsteam.functions.ps1",
"fileType": "functions",
"files": [
"./Private/*.ps1",
"./Public/*.ps1"
]
}To run build the script Build-Module.ps1. The script has the following parameters:
-outputDir 'C:\outputdir': The final module is stored in a dist folder by default. You can override this folder by using the parameter-buildHelp: Building help is skipped by default to speed your inner loop. Use this flag to include building the help-installDep: By default the build will not install dependencies unless this switch is used-ipmo: build module will be imported into session. IF a loaded module exist, it will be overwritten with the build version.-analyzeScript: run the static code analyzer for the scripts with PSScriptAnalyzer-runTests: runs the unit tests-testName 'tests to filter': can be used to filter the unit test parts that should be run. Wildcards can be used! See the Pester documentation for a more elaborate explanation.-codeCoverage: outputs the code coverage. Output by default is NUnit
Below are some examples on how to build the module locally. It is expected that your working directory is at the root of the repository.
Builds the module, installs needed dependencies, loads the module into the session and also builds the help.
.\Build-Module.ps1 -installDep -ipmo -buildHelpRuns all unit tests and executes the static code analysis.
.\Build-Module.ps1 -runTests -codeCoverage -analyzeScriptRuns the tests, but executes only the unit tests that have the description "workitems" for the logical grouped unit tests. This can be used if you only want to test a portion of your unit tests.
.\Build-Module.ps1 -runTests -testName workitemsThis project is licensed under the MIT License.