I want to create a deployment agent for my project in Azure DevOps.
I installed an agent and then managed to delete it using
./config remove
then rebooting
then removing the folder.
When I installed it again I got a message
The service already exists: vstsagent.dev.mycomputername, it will be replaced
Could not delete the service 'vstsagent.dev.mycomputername'
The deployment group shows as offline in Azure DevOps.
My case may give you some insight. I have tried several times of agent setup, so there's multiple services installed. What I need to do is execute ./config remove inside EVERY directory to remove all services before a fresh re-install. (So I executed this command 8 times here)
Related
What I have:
Several separate repositories with .NET solutions.
Each solution has a Service Fabric Project (.sfproj).
Each sfproj has a needed publish profile.
Local Service Fabric cluster, which is used for development/debugging.
What I need:
I want to create a ps script which will go solution by solution and deploy the projects to the local service fabric cluster. Right now I'm opening each solution in VS and I'm publishing the app from VS. And it takes a lot of time.
Main question:
How to write a command that will build and publish the sfproj using needed publish profile?
P.S.: I have read Azure service fabric create package command line question here. But I don't understand how to include the needed publish profile.
I use [Azure App Service deploy] task in Azure Devops pipeline to deploy the artifact to an Azure App service.
Everything worked well before but today it not work suddenly. It failed when i tried to deploy the artifact to the production slot (the slot marked production). But when i tested to deploy to deployment slots, it worked well.
I just got an error message that has no much detail in the log
Cleaning up temp folders from previous zip deployments and extracting pushed zip file C:\local\Temp\zipdeploy\534hsvxr.zip (80.94 MB) to C:\local\Temp\zipdeploy\extracted
[error]Failed to deploy web package to App Service.
[error]Error: Package deployment using ZIP Deploy failed. Refer logs for more details.
Anyone got the same issue before?
Thanks
It seems to be a source control issue. Just try going to the App Service Deployment Center blade and click "Disconnect" to disconnect your deployment. And then try to deploy it again.
I am working with a self-hosted agent to release code into a target on-prem server. In my case, I just want to copy a file from the artifacts directory (.exe file) into a folder on my machine. So I created a deployment group and installed the on-prem agent on this server. I created the release pipeline...but since I am just copying a file, I couldn't use one of the predefined templates. So I started with Empty Job. Then I added a step to copy the file using the "Copy Files" step. However, no where in this process is there a place to associate a deployment group. Some of the pre-defined templates have the option to specify the deployment group. But in an empty job with an added step, how do I specify the deployment group? Any ideas?
I was able to add a Deployment Group Job in the Tasks section of the pipeline. Originally I was using the default Task which was running on a Microsoft agent. So was able to delete that one and add a Deployment Group job.
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'm trying to set Build Server machine in way that Build Agent is configured on it, and is targeting Azure DevOps Service (Cloud) collection, or organization as it is named like that for now. There is established connection but problem that I'm faced with is regarding workspaces.
When I try to run build definition, checkout step fails due to "Can not determine workspace..." error. As I run the advised command
tf workspaces /collection:<collection_url>
on Build Server, I can build given project, but, when try another project, the same story. I have to run the mentioned command again (new workspace is appeared in the list) and then I'm able to build that project.
Can someone point me on right way in diagnostic or tell the cause/solution if faced with this already?
According to the description and this thread which i assume is also posted by you,seems the agent in Azure DevOps is the one you used in TFS which is called as migration.
As I run the advised command
tf workspaces /collection:<collection_url>
on Build Server, I can build given project, but, when try another project, the same story.
It looks like the build definition requires a specific workspace which you managed by manual command.
What about create a new agent in Azure DevOps which is quite simple see if the problem can be resolved.