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.
Related
Is it possible to clone or copy an Azure Pipeline Hosted Agent for use as a Self-Hosted Agent?
I'd like to reuse one of the Hosted Agents simply to enable me recreate and reuse all of its
capabilities, saving me the headache. Is this possible and if so I'd really appreciate some help.
Thanks
This is not possible, but you can try to reuse what is already available here https://github.com/actions/virtual-environments
This repository contains the source used to create the virtual environments for GitHub Actions hosted runners, as well as the VM images of Microsoft-hosted agents used for Azure Pipelines. To file bug reports, or request that tools be added/updated, please open an issue using the appropriate template. To build a VM machine from this repo's source, see the instructions.
So you can use the same scripts which are used to create Microsoft Hosted agents.
There is no such build-in feature.
Azure DevOps provides free hosted agents that have a predefined set
of tools installed and configured for building and releasing your
apps.
There is another option where you set up and manage your own agents.
This can be done by simply downloading the agent package, and run it
either on your local machine or any other computing platform even on
Docker container. It also gives you more freedom to install specific
dependencies for your build and release.
If you want to build your own agent during the pipeline. I would suggest you use Docker container to handle the process.
Microsoft has already created pre-configured container images on Docker Hub for everybody to use. But they’re Linux based and don’t contain any additional applications and/or packages so you’d probably still need to add those every time you run your build.
This repository contains images for the Visual Studio Team Services
(VSTS) agent that runs tasks as part of a build or release.
VSTS agent images are tagged according to the base OS, an optional
Team Foundation Server (TFS) version, and tools that are installed.
When used with VSTS, the agent version is automatically determined and
downloaded at container startup based on the account to which the
agent is connecting.
More detail step, you could refer this article: Build your own Azure DevOps agents with pipelines
I am getting my first VSTS build and release definitions setup.
Test server destination, on prem
project is using VS 2017 professional
Earlier I setup a private agent for doing the build, following this.
https://learn.microsoft.com/en-us/vsts/build-release/actions/agents/v2-windows?view=vsts
The agent installed fine and I can see it from build & release / agent pools
However, have now switched to using a hosted agent for that so I can remove the need to install visual studio on a test server.
Now I want to deploy the build to my test server, which is on premises. Do I need yet another agent or can I use the one I setup already. In other words are build agents separate from release agents? The agent I setup earlier is running as a service.
The build agent can be used in VSTS build and release, also the deployment group agent is configuring with build agent too.
You don’t need to setup another build/release agent, there are many tasks to deploy app to another server, such as IIS Web App Deployment Using WinRM, PowerShell on Target machine, Windows Machine File Copy.
The build and release agents are the same, but you have to install an on-premise agent to deploy your projects in your network. Is not that you can not use the hosted agent, but you would have to use WinRM and open you network, which may not be a good idea.
After you installed your on-premise agent, you don't have to install VS on the machine to run tests. You can add the following task to your release.
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.
I'm trying to use TFS 2015.1 on premise to build a CI pipeline for our dev & uat. I've created a vNext CI build, which builds fine. But when I want to add a deploy step for on prem IIS server, I only then see Azure Web Deployment options.
Ideally I wanted to add a step which uses the existing deploy (MS Deploy) profiles, which I'm able to use from VS2015 directly, using 'Publish'. However I see no option to do so.
How can I deploy the latest build to internal dev servers (not Azure)? I would like to use the MS Deploy option, unless there's a better way of doing it?
The fact that their is no option to starts to make me think there's probably a different way to accomplish it!
Thanks.
If you're able to upgrade to TFS 2015.2, web-based Release Management came out with it that works similarly to Build vNext with flexible and open-source tasks. You can also customize tasks.
Here's a link for IIS Web App Deployment from the vso-agent-task's GitHub repo where Microsoft stores updated versions of their tasks that you can download for web-based Build and Release Management.
I'll be publishing a blog about web-based RM with TFS 2015 Update 2 or VSTS on my website in the next few weeks. To give you an idea though, the starting point (for a web application) is a folder in your web project called WebDeploy (no significance - any name will do) that contains a PowerShell DSC script that configures the server, deploys the web files and then replaces any tokenised configs. To give you an idea see this post about how to use DSC to configure servers. (Only covers part of the final script though!) The next steps are:
In the build hub create a Website artifact - containing your web files and DSC script.
In the release hub for an environment use a Windows Machine File Copy task to deploy the artifact to a temp folder on the target node.
Then use a PowerShell on Target Machines task to execute the DSC script. After configuring the server the script copies the web files to their proper location, sorts out config using xReleaseManagement and cleans up the WebDeploy folder.
See this article for general details of the route I'm taking, but watch out as it has some errors eg the firewall instructions are incomplete (file and print sharing through the firewall needs to be enabled).
I can thoroughly recommend the PowerShell DSC route - I've had a few glitches but on the whole it feels very productive and the right way to be going.
We have Continuous Integration setup through TFS 2012.
Requirement:
Wanted the release build to be deployed on mulitple servers as a part of the CI. We need to do a xCopy of the files onto the server folders.
On TFS with Azure there seems to be a facility to publish it directly onto the server (http://www.windowsazure.com/en-us/develop/net/common-tasks/publishing-with-tfs/)
There-in it uses 'AzureContinuousDeployment.11.xaml' as the Build Process Template.
Wanted to check if anybody has tried similar publishing for custom/local servers, maybe using Custom deployment template, etc.
You likely want to create Standard Environments for Automated Deployment and Testing which you can do out of the box with TFS 2010. TFS 2012 and TFS 2013.
You use the "Lab Centre" which is part of the Microsoft Test Manager product to configure Environments that consist of one or more target machines.
You then use the Lab Default Template to push a build output to the target servers and execute a script to complete the install. You can even have your Integration and UI tests executed as part of the same actions.
If you are looking for more integrated Release Management with Team Foundation Server then you should look to Octopus Deploy as a good way to go all the way to production.
We use it with many of our customers and it works a treat...
From my understanding TFS 2012 ships with a Lab Deployment template. You configure the lab definitions of which servers are involved and then configure the deployments to those servers. Also used for hooking Test Manager in to run unit tests in the lab.