Do you have some process in development, which needs to be automatized and you are doing it for example by running PowerShell script with some parameters? Do you have problem with where to put the script and how to share all this with your colleagues? Do you have problem that someone is using old version of the script and some the newest one? Do you want to have some log who run it and with which values?
If yes, I want to offer you one feature of the Azure DevOps, which is available since March 2020. You can find the description here.
May be you are already using parameters in your YAML pipeline templates. You can now use same thing for whole pipeline. When you run such a pipeline manually, user can set the parameters and run the pipeline with them. It means, you can e.g. select what you want to do, which tasks to run or not to run, which image to use, whatever you can imagine. All what you need is to specify the parameters on beginning of your pipeline file in this format:
parameters: - name: myStringName type: string default: a string value - name: myMultiString type: string default: default values: - default - something other - name: myNumber type: number default: 2 values: - 1 - 2 - 4 - 8 - 16 - name: myBoolean type: boolean default: true
Do not forget that the parameters are available only during template parsing time, thus you can use them in ${{ }} expression where needed and the values will be used instead when the template is parsed. If you want to use them somewhere later, you should assign the values into variables and use them instead.
Ok, why it could be interesting for you? Because now you can create pipeline like "Create BC App", ask user for some values like App Name, Repository Name, ID range etc. and then as part of the pipeline, you can create the repository, initialize it with some templated files with correct final values (like new App ID, correct App name etc.), create the pipelines needed, write the app into your evidence and whatever you need. If someone need new app, he just run the pipeline and enter the parameters. You do not need to think about where to put the scripts (just store them to some repository), how to keep them up-to-date for everyone, how to set the permissions, and on top of all you will get traces about who created the app, you can get notification that some app was created... all these things which are standard in Azure DevOps. Why to not use them?
Do you need tool for creating new development environment? Create pipeline for it...
Do you need tool to run some maintenance like update licenses in your environments? Create pipeline for it...
My example for creating the BC App process:
parameters: - name: AppName displayName: Application Name type: string - name: RepoName displayName: Repository Name type: string - name: UserStoryID displayName: Connected User Story ID (0 if none) type: number - name: ObjectCount displayName: Object Count type: number default: 100 - name: ObjectStartID displayName: Object start ID type: number default: 55000 - name: Branch displayName: Template Source Branch type: string values: - v16_W1 - v16_CSY - name: Type displayName: Extension Type type: string values: - PTE - AppSource name: ${{ format('{0} {1}',parameters.AppName,'$(Rev:.r)') }} trigger: none jobs: - job: createApp displayName: Create the app pool: name: default workspace: clean: all steps: - checkout: git://BusinessCentral/BCPipelineScripts@master path: s/BCPipelineScripts - task: PowerShell@2 inputs: targetType: 'filePath' filePath: 'BCPipelineScripts\Scripts\New-BCApp.ps1' arguments: ${{ format('-AppName ''{0}'' -RepositoryName ''{1}'' -WIUserStory ''{2}'' -Branch ''{3}'' -ObjectCount {4} -StartId {5} -Type {6} -ADOUrl {7} -ProjectID {8}',parameters.AppName,parameters.RepoName,parameters.UserStoryID,parameters.Branch, parameters.ObjectCount,parameters.ObjectStartID,parameters.Type,Format('{0}{1}',variables['System.TeamFoundationCollectionUri'],variables['System.TeamProject']),variables['System.TeamProjectId']) }} displayName: Run script for creating the app name: runScript env: SYSTEM_ACCESSTOKEN: $(System.AccessToken)
Not really sure I like it. The old way of defining parameters, allowed you to create null value parameters. This way requires you to always have a default value, even if none exists.