Answers: <p>Closing this issue as we were able to modify the process with the teams involved to be able to define the variable when the release is created.</p>
  
  <p>Our answer is to modify the existing process and accompanying software to remove this need</p>
  
  <p>Edit: To clairify the software that activated the database was re-written to allow CLI variables to be passed, which can be set for each environment.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-07-20T19:58:29.113Z
Answers: 2018-10-03T14:23:21.357Z
Answers: 2018-10-03T14:23:21.357Z
Answers: xtreampb
Answers: <p>While you can use the Release Description field the moment you Start a Release</p>
  
  <p><a href="https://i.sstatic.net/s5Che.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/s5Che.png" alt="enter image description here"></a></p>
  
  <p>which fills in the <code>$(Release.ReleaseDescription)</code> variable, I discourage this approach.</p>
  
  <p>The whole point of a Release Pipeline is to automate and having users inputting data is against this approach.
  If you do not trust VSTS for Secrets, you can store them in Azure KeyVault or similar and pull them down while releasing. It is not a chance that there are <a href="https://docs.microsoft.com/en-us/vsts/pipelines/tasks/deploy/azure-key-vault?view=vsts" rel="nofollow noreferrer">Tasks</a> to facilitate this.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-07-20T14:11:18.197Z
Answers: It isn't an issue with trust, this variable value just isn't known until it is deployed into an environment, not when a release is created. so this wouldn't work.
Answers: xtreampb
Answers: CC BY-SA 4.0
Answers: 2018-07-20T14:21:56.903Z
Answers: This was not clear in your Q: please go back and edit it.
Answers: Giulio Vian
Answers: CC BY-SA 4.0
Answers: 2018-07-20T13:56:18.267Z
Answers: 2018-07-20T13:56:18.267Z
Answers: Giulio Vian
Body: <p>So I'm automating a process we currently have where we deploy a database and then have an exe that 'activates' the database.  The default values are different for each product and is determined by a cmd line arg.</p>
  
  <p>I've created 3 VSTS Release environments based on the hardware IO board for the environment.  How can I pass in this product flag at deploy time as it isn't dependent on the environment or release itself.</p>
  
  <p>Edit:
  The product flag value isn't known until the database is deployed into an environment, and value can not be set in the release definition creation time or at release time.  Only when deployed into a particular environemnt</p>
  
Tags: <deployment><azure-devops>
Title: VSTS deployment variable
UserDisplayName: xtreampb
ThreadText: # VSTS deployment variable
  
  (Asked by: username_0 on 2018-07-19)
  
  So I'm automating a process we currently have where we deploy a database and then have an exe that 'activates' the database. The default values are different for each product and is determined by a cmd line arg.
  
  I've created 3 VSTS Release environments based on the hardware IO board for the environment. How can I pass in this product flag at deploy time as it isn't dependent on the environment or release itself.
  
  Edit:
  The product flag value isn't known until the database is deployed into an environment, and value can not be set in the release definition creation time or at release time. Only when deployed into a particular environemnt
  
  **Tags:** deployment, azure-devops
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2018-07-20. Score: 0 | Accepted answer
  
  Closing this issue as we were able to modify the process with the teams involved to be able to define the variable when the release is created.
  
  Our answer is to modify the existing process and accompanying software to remove this need
  
  Edit: To clairify the software that activated the database was re-written to allow CLI variables to be passed, which can be set for each environment.
  
  
  ---
  
  ### Answer by username_1 on 2018-07-20. Score: 0
  
  While you can use the Release Description field the moment you Start a Release
  
  [![enter image description here](https://i.sstatic.net/s5Che.png)](https://i.sstatic.net/s5Che.png)
  
  which fills in the `$(Release.ReleaseDescription)` variable, I discourage this approach.
  
  The whole point of a Release Pipeline is to automate and having users inputting data is against this approach.
  If you do not trust VSTS for Secrets, you can store them in Azure KeyVault or similar and pull them down while releasing. It is not a chance that there are [Tasks](https://docs.microsoft.com/en-us/vsts/pipelines/tasks/deploy/azure-key-vault?view=vsts) to facilitate this.
  
  > **Comments:**
  > **username_0**: It isn't an issue with trust, this variable value just isn't known until it is deployed into an environment, not when a release is created. so this wouldn't work.  
  > **username_1**: This was not clear in your Q: please go back and edit it.  
  
  ---
  
  