Thank you for the video. It really breaks new comers disbelief that DevOps and CI/CD pipelines are only made for Azure like cloud environment deployment only! Definitely I will try to deploy our legacy web apps to on premises IIS servers and see how it goes and we can reduce the pain of manual deployment of my entire team. Additionally, I hope this on prem deployment would work well for my client network having multiple servers like Dev, UAT, QA and PROD behind a firewall, and hopefully should work for my tens of apps deployments on number of servers!
Clear as mud! "Yeah you can tweak your scripts to make them work" - thanks. A breakdown of what the scripts actually do would be useful. What if something goes wrong in the future - what chance do we have of supporting something like this? It all just seems very fragile and over-dependent on opaque tools which might not be around in say 5 years.
For every change that is made and published using visual studio project ,it creates .publish.sql file in bin folder. Do need to checkin these files to version control. Could you please clarify
Is there a cost for running each destination server as an agent as 16 servers behind the load balancer? I remember it costing about $5/month for each additional build server.
Hi DevOps team, Thanks for uploading On-Prim version with VSTS. I will definitely try this. Can you please provide me link of "Remote desktop manger free" version used into this video. I was searching on Microsoft.com and not able to find it apart from old version 2.7. Thanks, Chinmay
Hi guys, great video! This is exactly what I've been trying to do for the last week now, but I'm having issues when running the power shell script to install a release agent on my on prem VM environments - The script gets stuck when trying to establish a connection to the VSTS server and I suspect its something to do with the proxy/firewall. Do you have any tips or advice on how to get the communication running?
You need to create a .proxy file in the agent folder. We do this by editing the powershell script copied from VSTS to create the file between extracting the agent and running the configuration command. ...ExtractToDirectory( $agentZip, "$PWD");"yourproxyaddress:yourproxyport" | Out-File .proxy;.\config.cmd --deploymentgroup...
Sorry you're running into issues with the script, we strongly recommend posting questions like that over to forums or stackoverflow, there just isn't enough people monitoring this to help with specific issues.
This is not fully correct in the sense that there was a way to deploy in parallel without Deployment group, it just involves adding custom capability to the different servers in the Agent Pool and then adding 2 environments that each points to same agent pool but with different demand that matches the custom capability and then both environments can be set to run immediately after release so this in essence a parallel deployment. What both ways dont take into account is: 1. When using parallel deployments to part of all the agents in the pool, youre basically saying that those servers that haven't yet got updated to new version need to work with the new database schema so this is something that has be pre-tested and verified to not cause the application to fail on the non-upgraded servers 2. Normal application deployments should go: Copy files to web, stop pool, start DB update, start pool - so your web application can not start before the database update was fully deployed so in essence you have to swap context, either with a new environment added with a single task to start app pool or a new environment with a deployment group that has a single step...its still too much context switching that would be nice to solve more elegantly.
Thank you for the video. It really breaks new comers disbelief that DevOps and CI/CD pipelines are only made for Azure like cloud environment deployment only!
Definitely I will try to deploy our legacy web apps to on premises IIS servers and see how it goes and we can reduce the pain of manual deployment of my entire team. Additionally, I hope this on prem deployment would work well for my client network having multiple servers like Dev, UAT, QA and PROD behind a firewall, and hopefully should work for my tens of apps deployments on number of servers!
13:20 So for IaaS this is a must have scenario (with agents/deployment groups) ?
Clear as mud! "Yeah you can tweak your scripts to make them work" - thanks. A breakdown of what the scripts actually do would be useful. What if something goes wrong in the future - what chance do we have of supporting something like this? It all just seems very fragile and over-dependent on opaque tools which might not be around in say 5 years.
For every change that is made and published using visual studio project ,it creates .publish.sql file in bin folder. Do need to checkin these files to version control. Could you please clarify
How do you get it to deploy to an already existing website on pem
Is there a cost for running each destination server as an agent as 16 servers behind the load balancer? I remember it costing about $5/month for each additional build server.
Hello am trying to get a precise tutorial for deploying to ubuntu server and run systemd tasks
Hello Team,
Could you please make a video on how can we deploy a WPF/WINFORMS exe and dlls to a physical machine using Azure Devops
Hi DevOps team,
Thanks for uploading On-Prim version with VSTS. I will definitely try this.
Can you please provide me link of "Remote desktop manger free" version used into this video. I was searching on Microsoft.com
and not able to find it apart from old version 2.7.
Thanks,
Chinmay
Hi guys, great video! This is exactly what I've been trying to do for the last week now, but I'm having issues when running the power shell script to install a release agent on my on prem VM environments - The script gets stuck when trying to establish a connection to the VSTS server and I suspect its something to do with the proxy/firewall. Do you have any tips or advice on how to get the communication running?
You need to create a .proxy file in the agent folder. We do this by editing the powershell script copied from VSTS to create the file between extracting the agent and running the configuration command.
...ExtractToDirectory( $agentZip, "$PWD");"yourproxyaddress:yourproxyport" | Out-File .proxy;.\config.cmd --deploymentgroup...
Sorry you're running into issues with the script, we strongly recommend posting questions like that over to forums or stackoverflow, there just isn't enough people monitoring this to help with specific issues.
Dont run PowerShell ISE....the prompts do not show.
This is not fully correct in the sense that there was a way to deploy in parallel without Deployment group, it just involves adding custom capability to the different servers in the Agent Pool and then adding 2 environments that each points to same agent pool but with different demand that matches the custom capability and then both environments can be set to run immediately after release so this in essence a parallel deployment.
What both ways dont take into account is:
1. When using parallel deployments to part of all the agents in the pool, youre basically saying that those servers that haven't yet got updated to new version need to work with the new database schema so this is something that has be pre-tested and verified to not cause the application to fail on the non-upgraded servers
2. Normal application deployments should go: Copy files to web, stop pool, start DB update, start pool - so your web application can not start before the database update was fully deployed so in essence you have to swap context, either with a new environment added with a single task to start app pool or a new environment with a deployment group that has a single step...its still too much context switching that would be nice to solve more elegantly.
this is a nonsense, vsts currently look nothing like this