We created a release definition that deploys our build to a onsite IIS server. We need to be able to deploy to a subfolder (e.g. D:\apps\appname\v1\[deploy here]. We tried changing the Physical Path setting in the IIS Web App Manage task, but that changes the Physical Path of the entire IIS server.
How can we specify where we want to put our individual application?
The problem with the IIS Web App Manage task is that it wants to configure and create IIS Web Apps, not just copy files. To just copy files you want to use the Copy Files task. If you're working with a remote machine, make sure you're running the Copy Files task on your deployment group. To do that, in your Release Definition, make sure your task is running under a Deployment group phase that specifies your Deployment Group.
Once you have this set up, your deployment should run, and it will run from whatever machine you configured in the Deployment Group. You can copy files from the build's artifacts to a folder using a path local to that machine. So for example if your IIS Website is located at d:\websites\MySite you would use that as the destination path for the Copy Files task.
Related
I created a deployment group and able to create a agent on my server (linux machine) . Target machine was set. All I need was to create a release pipeline, So I created a release pipeline and select artifacts from build ( I already build that).
For Stage I select empty job and then select “Deployment Group Job” , Add my deployment group that I created and save the changes.
I select another task i.e “Copy Files” that copy files from artifacts to “/var/www/html” on my server(linux).
After this I run the release and deploy it. It succeed but what is does, that it copy zip file to the path I provide on my server.
/var/www/html/11.zip
That is not what I want. I want that it unzip the artifact that was built and deploy code to path I mention so that I can run my application there.
I may be choosing wrong task. But all I need it to run my application from my server. If I need to add some different task , what are those ?
If I need to add some different task , what are those ?
Since you need to deploy Unzipped files to the target path, you can directly use the Extract files task to replace the Copy file task in Deployment Group.
Here is an example:
In the Destination folder field , you could input the target path.
Then this task will unzip the zip file and send the unzipped files to the target path.
What options are there to deploy a web application to a heavily locked down machine without WinRM?
The situation is as followed.
Code is in Azure DevOps cloud
Release server is in a semi-secured area with access to download artifacts from DevOps
Target server is in a very locked down zone.
If release server can only copy files to a specific temporary folder target machine, is there a way to do deployment to it without WinRM?
My initial thought is to have a script on the Target machine to watch for the artifact showing up and deploy it. I want to know if there's a better way or if that's my best option?
If release server can only copy files to a specific temporary folder
target machine, is there a way to do deployment to it without WinRM?
If you've read document Deploy your Web Deploy package to IIS servers using WinRM, you would find the notice below the title:
A simpler way to deploy web applications to IIS servers is by using deployment groups instead of WinRM.
So you can consider using Deployment Group as a simpler direction. And here're some discussions(#1, #2) which may help you to do a choice between WinRM and Deployment Group depending on your needs.
Update1:
My initial thought is to have a script on the Target machine to watch
for the artifact showing up and deploy it. I want to know if there's a
better way or if that's my best option?
In your specific scenario, it's one choice when the target server cannot have line of sights to the Azure DevOp/TFS server and you can't(or maybe not want to) use WinRM.
I am trying to get Visual Studio Team Services (VSTS) to perform a web deploy of my app. According to the VSTS UI the web deploy is successful, but when I browse the deployed web site it shows the default IIS screen ("Welcome - IIS").
This is my publish step in the build pipeline:
This is my release definition:
This is the resulting deploy folder:
Build.log (with replaced values) - https://drive.google.com/file/d/1y6q2Cjr1gxBVMcHeh6n_r7qu-JpJFSyC/view
Do I need to add an additional step to the release pipeline to get the .zip files extracted?
You do not need to add an additional step to extract your zip, but you need to tell the IIS Web App Deploy task to deploy your zip file and not a folder. You have specified a folder for the Package or Folder input, so the task is doing exactly as you told it to do, deploy the specified folder.
If you only have one zip file in your build artifacts, the default value for this field, $(System.DefaultWorkingDirectory)\**\*.zip, will pickup your zip file and correctly deploy it. If you have multiple zip files in your build artifacts, you will need to specify the full path to the zip file in order for it to deploy.
I am using VSTS Release management to deploy artifacts to IIS websites. I have several Web applications and web services to be deployed. So, i am trying to figure out what sort of tasks that best fits my situation.
I have created a build definition with Visual Studio Build Task for projects as this one:
which works fine but i need to add a task for copying the artifacts Under IIS Website Directory.
The other approach is to use IIS web deployment as a task in Release definition, so I created the build definition as:
However, it expects a Publish Profile (the build fails because it can't find it). I don't need to create a publish profile for each project in the application because this would be too much work.
Is there is a workaround for that or what is preferred approach for this?
You can update your build definition to generate a web deployment package and upload it to artifacts. And then in Release Management, add a task to run "projectname.deploy.cmd" in the deployment package to deploy it to your IIS server. Refer to this link for details: How to: Install a Deployment Package Using the deploy.cmd File Created by Visual Studio.
And you can also enable FTP Publishing on your IIS server and add a task in your release to publish the artifacts via FTP. You may need this task:
FTP Uploader.
My Continuous Delivery with TFS / VSTS – Server Configuration and Application Deployment with Release Management blog post (with reference to some previous posts) has all the details you need for deploying your artefacts to target nodes using Windows Machine File Copy tasks then use PowerShell on Target Machines tasks to get them in to correct locations and to do token replacement and anything else that's required.
I would recommend using PowerShell DSC so that IIS is properly configured before deployment but that's not required. Where possible for web apps I favour keeping things very simple by creating artefacts that contain all the web files that are needed for a particular folder and then just using plain xcopy for the deployment.
If you need more control you can also use my MSDeploy VSTS extension to deploy a MSDeploy package
https://marketplace.visualstudio.com/items?itemName=rschiefer.MSDeployAllTheThings
https://dotnetcatch.com/2016/04/20/msdeployallthethings-vststfs-extension-is-public/
I am working on a CI process with automated deployment. TFS Build is building the solution, and it then uses an InvokeProcess task to kick off a Powershell script. The Powershell script deploys the database changes as a dacpac using sqlpackage, reporting services reports using the web service, fonts to the SSRS server, and the website itself to 1 or more web servers - the whole process uses a deployment configuration file to define drop paths, server ips, installation folders etc. There will be one of these per environment.
I would like to be able to build the solution and deploy to an internal server to run automated tests as part of the automated build. Once tests are completed, and the build has been manually checked, I'd then like to be able to kick off another Build definition which only has the deployment portion of the standard build template, which will simply take a build number or build drop location, and deploy the same build to a different environment (i.e. staging, prod etc.)
The issue I have is that I'm currently managing most of my web/app configuration using config file transformation - i.e. I have build definitions for Debug, Test, Prod etc. and then Web.Debug.config, Web.Test.config etc. I only want to carry out one build, and then deploy that same build to different environments, however at the moment the build will only generate configuration files for one environment - i.e. whatever the build configuration is.
Would the best approach be to generate all config files (or actually pre-createg complete config files for each environment), and then just choose the appropriate one for the specific deployment? Or should I store the env specific config in my deployment configuration file and update the appropriate keys using powershell when deploying?
What would be the normal/recommended approach here?
I'd suggest creating new Configurations for each target environment (e.g. by default you have Debug/Release, create some more). Then use the built-in web.config transforms, for non web-projects use Slow Cheetah
This will spit out pre-configured build outputs for each configuration you specify you want build (in your Build Definition).