en-us/about_AutomatedLab_cicd.help.txt

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
TOPIC
    about_automatedlab_cicd
 
SHORT DESCRIPTION
    Generic help about the Role 'cicd' in AutomatedLab
 
LONG DESCRIPTION
CI/CD Pipeline
    AutomatedLab now also lets you create release pipelines inside your lab by
    making use of AutomatedLab.Common's new TFS cmdlets.
 
    THE LAB
    Your lab should include at least one TFS 2017 server and a suitable SQL 2016
    server. You can use the sample provided at
    DSC with release pipeline
    .
 
 
    Add-LabMachineDefinition -Roles Tfs2017
    Add-LabMachineDefinition -Roles TfsBuildWorker # Optional, directly adds build workers to your TFS agent pools
 
    THE PIPELINE
    Before starting you should have an understanding of what a release pipeline
    is. There are plenty of resources out there. Especially for DSC, you could
    have a look
    here
    .
To add a new pipeline in AutomatedLab, here are the two cmdlets.
 
    GET-LABBUILDSTEP
    This cmdlet lists all available build steps that you can configure since
    there is not much documentation available. The output of `Get-LabBuildStep`
    can be copied and pasted with the correct formatting to use with
    `New-LabReleasePipeline`.
 
    NEW-LABRELEASEPIPELINE
    This cmdlet goes through the necessary steps to create a new CI/CD pipeline.
    A project will be created, if specified a git repository will be forked and
    pushed to the new team project's repository and the build definition will be created.
    The build definition is the only thing that requires some though. Since a
    build definition consists of multiple build steps you will need to select
    for yourself which steps might make sense.
 
    $buildSteps = @(
        @{
            "enabled" = $true
            "continueOnError" = $false
            "alwaysRun" = $false
            "displayName" = "Execute Build.ps1"
            "task" = @{
                "id" = "e213ff0f-5d5c-4791-802d-52ea3e7be1f1"
                "versionSpec" = "*"
            }
            "inputs" = @{
                scriptType = "filePath"
                scriptName = ".Build.ps1"
                arguments = "-resolveDependency"
                failOnStandardError = $false
            }
        }
    )
     
    ## Clone the DSCInfraSample code and push the code to TFS while creating a new Project and the necessary build definitions
    New-LabReleasePipeline -ProjectName 'ALSampleProject' -SourceRepository https://github.com/gaelcolas/DSCInfraSample -BuildSteps $buildSteps
 
 
    The `ID` you can see in the little code sample refers to the build step
    `ID`. This is part of the output of `Get-LabBuildStep`:
 
    @{
                enabled = True
                continueOnError = False
                alwaysRun = False
                displayName = 'YOUR OWN DISPLAY NAME HERE' # e.g. Archive files $(message) or Archive Files
                task = @{
                    id = 'd8b84976-e99a-4b86-b885-4849694435b0'
                    versionSpec = '*'
                }
                inputs = @{
                                    rootFolder = 'VALUE' # Type: filePath, Default: $(Build.BinariesDirectory), Mandatory: True
                                    includeRootFolder = 'VALUE' # Type: boolean, Default: true, Mandatory: True
                                    archiveType = 'VALUE' # Type: pickList, Default: default, Mandatory: True
                                    tarCompression = 'VALUE' # Type: pickList, Default: gz, Mandatory: False
                                    archiveFile = 'VALUE' # Type: filePath, Default: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip, Mandatory: True
                                    replaceExistingArchive = 'VALUE' # Type: boolean, Default: true, Mandatory: True
     
                }
            }