I have an ASP.NET Core solution and I am using Visual Studio Team Services Continuous Integration to build and push the images into the Azure Container registries repositories. Until now all are fine; now I am trying some way to push those images to a Linux Ubuntu Server that is also hosted in Azure, but the PowerShell on Target Machines won't execute the script to the remote server.
There are any way to make the server load the new images when they are available?
You can use the dedicated Docker tasks, which are cross-platform, or you can use SSH task to run a script on a Linux machine using SSH.
Related
My requirement is - Automate the PostgreSQL scripts from azure devops without installing any client tools/drivers on my local machine. We have couple of .sql, .fct and .prc files in repository. Pipeline should pickup these files and connect azure Postgres server and run the scripts.
PostgreSQL is integrated in the Microsoft hosted agent, you can consider using the hosted agent to run the pipeline.
About the software installed on the hosted agent,please refer to this document.
I have multiple ASP.NET web applications which I want to release into different VMs. Manually installing a DevOps agent in every single VM seems really inefficient. Is there a way to make this process faster? Is it possible to create release pipeline that could directly push the code to the public ip of the VM?
As workaround, you can prepare scripts to register each new agent. Here you can find parameters: Self-hosted Windows agents - Unattended config.
If you deploy your web application with IIS deployment task,
You can have a try using task Manage IIS, which can create website in a remote machine.
And then you can add a Windows machine file copy task to copy the build artifacts to the website Physical path in the remote machine.
Another workaround is that you can manage IIS with powershell script. So that you can add task PowerShell on target machines to run powershell script to manage IIS website. You can refer the example scripts at this page, and this page. For more information about IIS powrshell command you can refer here
I am trying to implement CI/CD for a web application hosted in a local network. Which means the local machine/IIS server which hosted the web application is not directly connected to the internet (so not a VSTS agent).
So we are putting a virtual machine acts as an intermediary between internet & local intranet machines. The Azure DevOps release pipeline will copy the deployment package to this "Virtual Machine"
Now I want to deploy this package to another machine in the local network which is actually hosting the application for an intranet. How can we achieve this step in the release pipeline?
I have tried below solution and it seems ok for me.
From Azure Release Pipeline, copy the build artifacts to a local path in the server (mentioned as "Virtual machine" in question)
Using MSDeploy.exe to deploy the release artifact to an intranet website hosted on "Local Machine" IIS.
https://learn.microsoft.com/en-us/aspnet/web-forms/overview/deployment/web-deployment-in-the-enterprise/deploying-web-packages
Note: The destination local machine should be configured for WebDeploy as instructed in https://learn.microsoft.com/en-us/aspnet/web-forms/overview/deployment/configuring-server-environments-for-web-deployment/configuring-a-web-server-for-web-deploy-publishing-web-deploy-handler
I am working for a WPF application, and recently I have migrated TFS to Azure DevOps and I am successfully able to create build artifacts as well, unfortunately, I could not create executable from the artifacts as Azure DevOps does not support InstallShield Package creation with it, now I decided to move the build artifacts to my local build server,again my company law doesn't allow to access my server from outside network, what should do to create executable.
The Build Agent needs to be able to connect to Azure DevOps. It's enough for it to be able to make an outgoing connection over https (443). The agent can be configured to connect through a web proxy server.
What alternatives do you have:
Use the hosted agent and install InstallShield as part of the build process. This will be slow, but it is doable. You'll need to execute this step as part of every build that tries to create the InstallShield package and requires you to do a head-less installation of InstallShield (given that they are the kings of Installers, I suppose this is doable).
Use a private agent in Azure. You can spin up any IaaS server on Azure, install Visual Studio, InstallShield and the Azure DevOps Agent on it and use it as a build server. There is a set of standard images file available which you can use as a basis.
It doesn't look like this is possible but is there a way to use VSTS Continuous Delivery and deploy to a server outside Azure?
Sure. VSTS Continuous Delivery can deploy to anything that can run the VSTS agent or anything that can be targetted from a VSTS agent. Basically you have two options:
Let the VSTS (hosted) agent communicate directly to your deployment target. Out of the box tasks can use MsDeploy or WinRM. There are also tasks for Octopus Deploy, AWS and other systems available through the Marketplace. Powershell has options to connect directly to other systems and you can use many different protocols from a powershell script.
Install the VSTS agent on your target machine (or network). The VSTS agent can be downloaded and installed onto the target server. That way you have full local access to the target machine and can simply copy the files to the target folder straight from the Release Management artefacts. By installing a VSTS agent in you local network, you can use the options listed under 1 to bypass firewalls that might be blocking the hosted agent.