Home → Questions →

Triggering Deployment Project From Environments

• Edit

Eric Mooney

30 Nov, 2016 10:55 PM

Is there a way to utilize the approach described here https://www.appveyor.com/blog/2015/11/04/deployment-projects/ but to actually have multiple deployment projects for a set of main projects. I would like to have separate deployment environments for our. I thought about using the webhook deployment provider to trigger a specific deployment project but I'm not sure what url to use for the webhook.

1. 1 Posted by Ilya Finkelshte... on 01 Dec, 2016 12:39 AM

   

   Hi Eric,

   What about different option -- create multiple deployment environments, and call them with API, and use API to ensure that they completed OK.

   Please look at this sample.

   Let us know if this can work fro you.

   --ilya.

   • Edit

2. 2 Posted by Eric Mooney on 01 Dec, 2016 01:16 AM

   

   I'm not sure that this script does what I am asking. Let me explain it better. If I have two projects (we'll call them project A and project B), I want them deployed to the same azure cloud service. I would use a deployment project to pull in the artifacts from these projects and deploy them together. What I want to do is to be able to then promote the build for one of the projects (lets say project A) to a staging environment. The staging deployment needs to deploy both project a and project b but should know to only pull the update for project A and to use an existing artifact for project B.

   • Edit

3. 3 Posted by dragon788 on 01 Dec, 2016 08:13 PM

   

   Eric, if you publish those packages to your personal feed (in AppVeyor), then you could certainly create another project that has your Azure server as the deploy target and run a script to grab those previously built packages and push them. If you are using something like a .nuspec file you could easily leave the dependencies open so that it will pull the latest of A or B, and you could also use the "cache folder" option in AppVeyor so it shouldn't have to redownload the second package.

   There might be a slightly cleaner way to do it, but that should work.

   • Edit

4. 4 Posted by Ilya Finkelshte... on 06 Dec, 2016 08:18 AM

   

   @dragon788 thank you! However I think that Eric needs something different.

   Eric, do I understand you correctly if I describe your requirements this way:

   • Single deployment project which by default deploys artifacts from the latest build from ProjectA and ProjectB

   • Ability to call deployment project with parameter, which can be used to dictate what build version to use when downloading artifacts specific project.

   If my understanding is correct, this should be doable:

   • Please note that among other variable you have to set the following:

     deploy_version - build version to deploy. If not specified artifacts from the most recent version will be downloaded.

     You probably will have to setup it twice, for both ProjectA and ProjectB, like deploy_version_a and deploy_version_b. Then each of them will be passed to deploy.ps1 which will download artifacts. By default it is empty which will make it use latest build.

   • So for staging deployment you can alter this variable to use older build version for ProjectB. To start deployment build and pass specific environment variable you can use API. So you just pass specific value of deploy_version_b when starting deployment project build.

   Here is sample of PS script to start this deployment:
   

   $deploy_version_b = <set_your_previous_version_for_projectB_build>
   $token = '<your_api_token>'
   $headers = @{
     "Authorization" = "Bearer $token"
     "Content-type" = "application/json"
   }
   $body = @{
       accountName="<your_account_name>"
       projectSlug="<your_deployment_project_name>"
       branch="master"
       environmentVariables = @{
          deploy_version_b=$deploy_version_b
       }
   }
   $body = $body | ConvertTo-Json
   Invoke-RestMethod -Uri 'https://ci.appveyor.com/api/builds' -Headers $headers  -Body $body -Method POST
   

   Hope this helps.
   Ilya.

   • Edit

5. Ilya Finkelshteyn closed this discussion on 25 Aug, 2018 02:10 AM.