Any common/standard way for pulling latest versions of apps to newly launched instances?

brian.donahue's Avatar


13 Dec, 2017 05:21 PM

We are setting up an AWS Windows environment, and currently are using the Appveyor Agent to deploy to existing instances which works well. We basically have each Auto Scaling Group assigned to a Deployment Group and all instances get the same apps for that Deployment Group.

But when a new instance comes online, we need to deploy the current versions of all apps in the deployment group on the new instance. Is there a way to trigger that via the Agent (assuming not). To use Appveyor Agent, it would seem the only way would be to poll for the deployments, and trigger new deployments of latest version via Powershell?

Are there other/better ways that people have done this? One option I'm looking at is deploying to S3 and using CodeDeploy which does support "deploy-on-launch" of latest versions.


  1. Support Staff 1 Posted by Ilya Finkelshte... on 14 Dec, 2017 04:19 AM

    Ilya Finkelshteyn's Avatar

    Hi Brian,

    I believe the following scenario will work:

    1. For specific Environment, set deployment group name to be an environment variable as described here. Set existing value as default value so default behavior do not change.

    2. On lunch of new instance set deployment group to computername environment variable. If you install AppVeyor deployment agent on startup, you probably already use DEPLOYMENT_GROUP command line parameter. If it is pre-installed, update it in registry key HKEY_LOCAL_MACHINE\SOFTWARE\AppVeyor\DeploymentAgent value name DeploymentGroup.

    3. After that (also part as startup script) start Environment deployment with API. Pass deployment group computername as environment variable (which you set in the step 1), so it will overwrite default deployment group and deployment will happen only to this instance.

    4. In deploy.ps1 script, which happens after deployment, reset deployment group name in registry to default value. If you have a risk that the same deploy.ps1 will be called on instances in the different AWS scaling groups, send special environment variable (like default_deploy_group) when starting initial deployment on step 3 and make deploy.ps1 use it when editing the registry.

    Hope this make sense. It can look complicated, so feel free to ask any additional questions. Also we are happy to help with script samples if needed.


  2. 2 Posted by brian.donahue on 08 Jan, 2018 09:56 PM

    brian.donahue's Avatar

    Thanks - I have been playing with this and got it working, but now seem to be seeing some issues with the agent attempting to run two deploys simultaneously on the same group (machine, in this case). Is this intended behavior? It is causing sporadic failures as one deploy sets different environment variables than the other. E.g. an APPLICATION_PATH env var in one deploy is sometimes getting a value from another. Do I have to manage this in my script to ensure the deployments execute serially? Shouldn't the agent handle that?

  3. 3 Posted by brian.donahue on 08 Jan, 2018 09:58 PM

    brian.donahue's Avatar

    To clarify, my instance serves multiple applications, and I am triggering the latest deployment for each project in my script. I figured they'd be queued serially, but they seem to run in parallel and that causes issues.

  4. Support Staff 4 Posted by Ilya Finkelshte... on 09 Jan, 2018 07:20 AM

    Ilya Finkelshteyn's Avatar

    I see. Created this issue. We believe we can implement it by the end of this week. Would you mind to test pre-release agent version as it available?

  5. 5 Posted by brian.donahue on 09 Jan, 2018 06:51 PM

    brian.donahue's Avatar

    That's awesome - I'm happy to help test!

  6. Support Staff 6 Posted by Ilya Finkelshte... on 27 Jan, 2018 04:37 AM

    Ilya Finkelshteyn's Avatar

    Hi Brian,

    Sorry it took longer than expected (recent update took a lot of time). Can you please try and see if problem disappears. No PowerShell colors with this implementation though, but I don't think you care too much :)


  7. 7 Posted by brian.donahue on 29 Jan, 2018 03:59 PM

    brian.donahue's Avatar

    Hi Ilya,

    I tested this several times, and have not reproduced the issue. I am also going to test it on spinning up new instances in an ASG, which is where I first saw it. In the meantime, I am having another issue with this approach that I don't understand. I added ${deployGroup} as an environment setting for this project, and it works in my PS script when I set it to machine name, and also works when pushing to github, and setting it in appveyor.yml but triggering a deployment from the Appveyor console does not triggering any agents. I can't tell what ${deployGroup} is being set to in that case, but I thought it would pick up the variable in the appveyor.yml, though it seems it doesn't... how can we get it to work from the Appveyor console/UI so that we can do things like roll back to previous versions? Can we only do this with the API now if we use ${...} variables like this?

  8. 8 Posted by brian.donahue on 29 Jan, 2018 04:30 PM

    brian.donahue's Avatar

    Hi Ilya,

    Actually, I realized that I can set a default value in the Env Vars settings on the Environment. But that comes with another potential issue... I had been using a single ${deployGroup} var name for all my apps, but having one default for that variable will cause issues (all apps deployed to same group when deployed via console). I guess you need a different environment variable name per Deploy Group, like app1DeployGroup app2DeployGroup.

    This means I need I need another variable in my script to know which env variable to set with the deploy group, which is kind of ugly, though not the end of the world. :( Not sure how that can be improved. One idea that crossed my mind was allowing some sort of default to be set in environment settings like :
    app1.deploy_group: ${deployGroup:app1group} where app1group is the default if none is specified. Not sure that's very nice either. Let me know if you have thoughts....

  9. 9 Posted by brian.donahue on 29 Jan, 2018 05:00 PM

    brian.donahue's Avatar

    Alas, I think the ultimate solution would be to enable triggering the appveyor agent locally (CLI or API) to pull a specific deployment to the target machine, similar to how CodeDeploy agent works in AWS. I would love to stick with Appveyor deployment, as I love the IIS integration, etc, but CodeDeploy has the edge here.

  10. Support Staff 10 Posted by Ilya Finkelshte... on 31 Jan, 2018 10:37 PM

    Ilya Finkelshteyn's Avatar

    Hi Brian,

    Sorry it took some time for me to digest the situation. Hope I understand it correctly. What about separate Environment (each with the same Environment access key) for each app? This will make PS script on local instance a little bit more complicated, but not to much.

    Let us know what you think.


  11. 11 Posted by brian.donahue on 06 Feb, 2018 02:25 PM

    brian.donahue's Avatar

    Been mulling this over. I think the multiple environment approach is our best bet. Took me a while to warm to the idea of having multiple environments for one conceptual environment like "production" but as we break our app into smaller and smaller sets of services I think it will actually make it easier for us to manage. Will give that a shot. Thanks for your help! I think I still might make a feature request for a CLI/API call that we can use to trigger deploying the latest version of all projects in an environment to that machine though :)

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:


Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac