Skip to content

Commit

Permalink
fixed pipeline variable reference
Browse files Browse the repository at this point in the history
  • Loading branch information
alex-frankel committed Sep 15, 2019
1 parent b68c6e0 commit a000f17
Show file tree
Hide file tree
Showing 2 changed files with 4 additions and 2 deletions.
2 changes: 1 addition & 1 deletion azure-pipelines.yml
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ pool: 'Hosted VS2017'
variables:
- name: spnName
value: 'pipelines-runner'
- name: blueprintPath
- name: blueprintsPath
value: '.\samples\'
- name: blueprintName
value: '101-boilerplate'
Expand Down
4 changes: 3 additions & 1 deletion pipelines-scripts/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,6 +11,8 @@ This directory has two scripts - `build.ps1` and `release.ps1` that collectively

While this is more specific to Azure DevOps pipelines, **the methodolgies and strategies apply just as well to any other release management tool.**

**NOTE:** If you *are* using Azure DevOps Pipelines, we highly encourage you to use Neil Peterson's Azure Blueprints DevOps extension. These are more heavily tested, more fault tolerant, and better maintained than the build/release scripts in this repo.

## How to use this guide
The `azure-pipelines.yml` build pipeline definition has variables set up to do a full release on the `101-boilerplate` blueprint. If you want to test a different blueprint, change the varaibles at the top of that file and [change your parameters and test environment](#to-configure-your-release-test) accordingly

Expand All @@ -21,5 +23,5 @@ This does steps 1 and 2 above. For the most part, this script is pretty straight
This does steps 3 and 4 above. You can choose to run this in a build pipeline or a release pipeline. If you are solely validating that the blueprint is working as expected, I recommend keeping it in build. If you are planning to do a rollout of a blueprint to dev -> QA -> pre-prod -> prod (or some equivalent), I would recommend using Release Pipelines and using some sort of validation between each release stage.

### To configure your release test ###
Each blueprint will have it's own parameters and their own "expected state" for what the environment should look like when it is applied. You will need to update lines `61` to `65` based on the parameters of the blueprint, and you will need to also account for what the test environment looks like between lines `50` and `56`
Each blueprint will have it's own parameters and their own "expected state" for what the environment should look like when it is applied. You will need to supply your own assignment parameters file which will also need your `blueprintId`.

0 comments on commit a000f17

Please sign in to comment.