We're using an on-prem VCS and CI pipeline, and don't have plans to switch to VSTS right now. However, I'd be very interested in running cloud-based load-tests against our app as part of our CI pipeline. In order to do this, I'd have to be able to programmatically upload the loadtest script and invoke it from VSTS.
Is this possible?
Yes, it is possible, the workflow like this:
1.Create a valid loadtest file. You can use the load test file from an earlier run through Visual Studio for this.
2.Create a location to upload the file(s). This location is a drop folder on Azure Blob and is below referred to as "TestDrop".
3.Upload the loadtest file and any other files required for the run, this includes the webtest files, settings file, etc. to this location or "TestDrop".
4.Create a Test Run using the Testdrop from the previous step as all the files required for a run are now available at the drop location.
5.Start the run.
6.Once finished, download the results to your local machine. This will be a gzip file. Uncompress it to get the results file.
7.Use Visual Studio to view the downloaded results.
More information, you can refer to this article, which contains samples.
Related
I am building a very small Node/Express API app in Azure using Twilio to route communication for a small group. I initially built out a data structure for users in CosmosDB but found out it's minimum $24 per month, which is way over budget for something that will likely hold 20 or so records. Because of this, is seems much more reasonable to just build this into a json file that sits in a ./json subfolder. However, it has occurred to me that whenever I deploy, I would be overwriting this file with the default file I have locally. I have been working via the Azure App Service tool in Visual Studio Code and can't figure out a way to make it ignore the file.
I can go into Kudu and copy the file down each time before I deploy, but I will eventually forget and this sounds like a very brittle process.
I added a json/ line to .gitignore, but that has no effect on the deployment (as expected).
I also added "appService.zipIgnorePattern": ["json{,/**}"] to the settings.json file, but instead of just ignoring that folder on the server, it erases it on deploy (the zip ignores it and then it wipes/replaces the whole wwwsite folder). Looking for the file gives me {"Message":"'D:\\home\\site\\wwwroot\\json\\users.json' not found."}
I was hoping there is a setting that would deploy, replacing all folders in the package, and ignoring all content in the ./json folder. Does this exist?
Alternative solution, 2021:
Instead of excluding folders, select the folder that you do want to deploy. Data in other folders will not be affected.
Deploy from: edit .vscode/settings.json in your local project and add "appService.deploySubpath": "./folderToDeploy"
Deploy to: In the Azure Portal go to your app service. Under Configuration / Application Settings add a new Application Setting with name SCM_TARGET_PATH and value ./folderToDeployTo
Using VS Code right+click deploy will deploy the contents of the folder. I was able to work around this by adding Azure as a remote branch and using .gitignore. I placed my json file inside a random folder (content/json) then placed /content/json in my .gitignore file.
Is it possible to browse the file system in Azure Devops. Like when using SSH to connect to a server? Or if it's possible to browse using Explorer.
It would really simplify things if I could see what files were created and where they end up after builds.
Now I don't feel I have any way to know which files ended up where after the builds are done.
Thanks!
I don`t think so. You may add build steps (Build and release tasks - Utility) and create cmd or bath file to browse the file system of the build servers.
As alternative way, you may use your own build server (Self-hosted agents) on Azure VMs and you will have the full control.
I'm trying to upload log files created by a 3rd party exe during a deployment and including it in the results of my deployment, on a separate tab if possible.
I tried using the publish artifact build tasks but that only works for build not release.
I tried logging tasks but ##vso[build.uploadlog]<local file path> seems to be for builds as well since it complains about finding a container for the build.
Release management does not have a container for build artifacts, that's why you see this error message.
You can try with following task:
Write-host "##vso[task.uploadfile]<filename>"
View and download attachments associated with releases
Would you like to upload additional logs or diagnostics or images when
running tasks in a release? This feature enables users to upload
additional files during deployments. To upload a new file, use the
following agent command in your script:
Write-host "##vso[task.uploadfile]"
The file is then available as part of the release logs. When you
download all the logs associated with the release, you will be able to
retrieve this file as well.
You can also add a powershell script task in your release definition to read the log files and output it to the console. Then you will be see the content of the log files from "Logs" tab powershell script step. And you can also click "Download all logs as zip" to download the logs.
I hope to provide more clarity to those looking for an answer. The accepted answer does work.
I had a lot of files (browser screenshots) to add to the release logs. Here's what I did:
If you have lots of files, Archive them into a zip.
Attach the zip to the log files via powershell.
Download the logs
Unzip and enjoy!
#DonRolling, thanks for the detailed answer. In my case instead of adding a new task to compress the folder i just included that part in the powershell:
Compress-Archive -Path "$(System.DefaultWorkingDirectory)/TestFolder/ScreenShots" -DestinationPath "$(System.DefaultWorkingDirectory)/TestFolder/ScreenShots" -Force
Write-host "##vso[task.uploadfile]$(System.DefaultWorkingDirectory)/TestFolder/ScreenShots.zip"
I was facing a similar problem but I also wanted to use the Artifacts in a subsequent agent phase.
Based on the previous answers I created an Extension that offers the possibility to:
Upload a file or a folder to the Release Logs
Automatically download an Artifact from the logs that was previously uploaded
The upload task is making use of the logging command as it was mentioned before. The download task then queries the Azure DevOps REST Api to download all logs collected thus far, tries to find the specified artifact and copies it to a specific place.
If anyone is interested, it can be found on the Marketplace
I have a Windows Azure Website and I've setup Azure Continuous Integration with hosted Team Foundation Server. I make a change on my local copy, commit to TFS, and it gets published to Azure. This is great, the problem is that I have an Access database in the ~\App_Data\ folder and when I check-in the copy on Azure gets overwritten.
I setup a web-deploy publish profile to "Exclude App_Data" and configured the build task to use the web-deploy profile, and now it DELETES my ~\App_Data\ folder.
Is there a way to configure Azure Continuous Integration to deploy everything and leave the App_Data alone?
I use the 'Publish Web' tool within Visual Studio, but I think the principles are the same:
if you modify a file locally and publish, it will overwrite whatever's on the web
if you have no file locally - but the file exists on the web - it will still exist on the web after publishing
The App_Data folder gets no special treatment in this behaviour by default. Which makes sense - if you modified an .aspx or .jpg file locally, you would want the latest version to go on the web, right?
I also use App_Data to store some files which I want the web server (ASP.NET code) to modify and have it stay current on the web.
The solution is to:
Allow the web publishing to upload App_Data, no exclusions.
Don't store files in App_Data (locally) that you want to modify on the web.
Let the web server be in charge of creating and modifying the files exclusively.
Ideally you would not have to change any code and the server can create a blank file if necessary to get started.
However if you must start off with some content, say, a new blank .mdf file, you could do the following:
Locally/in source repository, create App_Data/blank.mdf (this is going to be a starting point, not the working file).
In Global.asax, modify "Application_Start" to create the real working .mdf file from the blank starting file:
// If the real file doesn't exist yet (first run),
// then create it using a copy of the placeholder.
// If it exists then we re-use the existing file.
string real_file = HttpContext.Current.Server.MapPath("~/App_Data/working.mdf");
if (!File.Exists(real_file))
File.Copy(HttpContext.Current.Server.MapPath("~/App_Data/blank.mdf"), real_file);
We have a couple of cloud services and do a Continuous Delivery to a test environment via Team Build.
For the production environment, we have our own deployment powershell script. This script needs a .cspkg file for deployment.
My problem is now that I haven't found a way to let team build just create a .cspkg file but not to publish it to Azure.
I've used the AzureContinousDeployment.11.xaml template and it insists on publishing the package.
I've tried to set the "Deployment Settings Name" to an empty string. The build runs without errors, but that way, no package is created.
Is there a way to stop it somewhere in between?
Maybe something I could change in the .azurePubxml file to achieve that?
Environment: VS2012, Team Foundation Service (visualstudio.com)...
On the Process tab of the edit definition:
If you clear out the Deployment Settings Name and all the values under Publishing - Azure Cloud Service and Publishing - Azure Website (except you can leave True for the Allow Upgrade) the building template won't know where to publish the project.
Also on the Build Defaults tab of the edit definition:
Select the "Copy build output to the following Source Control folder (this folder will be created if it does not exist):"
Add some name and path like: "$/your cloud service/drops"
That will cause all your builds to be moved to the drops folder after a successful build. In those drops folders, there will be a app.publish directory that will have your *.cspkg and *csfg files.
I have my custom build template xaml invoke the MSBuild task (Microsoft.TeamFoundation.Build.Workflow.Activities.MSBuild) on the Azure project (.ccproj file) with the "Publish" target.
(Despite having the same name as the UI command that pushes the package to Azure, the "Publish" target just means "generate the package without pushing it anywhere".)