I am new to Team Foundation Server and trying to setup process which automatically publishes files to ftp server once I check in files. Do we have any easy trick to do that in TFS.
You can use TFS build for that. Create a Continuous Integration build ( see URL below) and setup the drop location for the build.
http://msdn.microsoft.com/en-us/library/hh395023(v=vs.110).aspx
After that see below URL on how to upload the build to FTP from the drop location.
http://jpadda.wordpress.com/2012/01/06/tfs-2010-upload-build-from-droplocation-to-ftp-activity/
Related
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.
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'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.
Trying to make my life easier, Currently we have 4 developers working in Visual Studio 2012 and we are using TFS 2012 for source control. The project we work on is a multi-tenant web application (single source directory with multiple dbs) that is a mixture of legacy, asp and vb6 com components, coupled with new C# code. We use TFS for source control and for managing User Stories and Bugs. Because of the way our site works it can not be ran or debugged locally only on the server.
Source Control is currently setup with a separate branch for each developer that's working directory is mapped to a shared network path on the dev server that has a web site pointed to it in IIS. Dev01-Dev05 etc. The developers work on projects in their branch test it using their dev website, then check in changes to their own branch and merge those into the trunk. The trunk's work space is mapped to the main dev website so that the developers can test their changes against the other customer's dev domains to test against customizations and variances in functionality based on the specific dbs the are connected to.
Very long explanation but basically each dev has a branch and a site, that are then merged into the trunk with its own site.
In order to deploy our staging server:
I compile the trunk's website via a bat file on the server
Run a windows app I built to query TFS for changesets associated with
specific WorkItems in a certain status, and copy all the files for
those changesets from the publish folder to a deployment folder.
Run another bat file on the server to use RedGate's Deployment Manager
to create a package from those new files
Go to the DM site on our network to create and deploy that release (haven't been able to get the command line tools to work for this, so I have to do it manually)
Run any SQL scripts that have been saved off in Folders that match ticket numbers on each database (10 or so customer dbs) to support the release
I have tried using TFS automated build stuff and never really got it to build the website correctly. Played around with Cruise Control also with little success. Using a mishmash of skunk works projects to do this is very time consuming and unreliable at best.
My perfect scenario would be:
Gated Checkin, Attempt build/publish every time a developer merges into the trunk, rejects and notifies developer if the build fails.
End of the day collect the TFS Items of a certain status and deploys files associated with them to the staging site
Deploy SQL scripts for those TFS items across all the customer dbs in staging
Eventually* run automated regression UI tests, create new WorkItems or emails to devs if failed
Update TFS WorkItems to new state so QA/Customers know their items are ready to test in our staging environment
Send report of what items were deployed successfully
How can I get here so that I am not spending hours preparing and deploying releases to staging and eventually production? Pretty open to potential solutions, things that would be hard to change would be the source control we are using, can't really switch to subversion or something else so we are pretty stuck with TFS.
Thanks
Went back in and started trying to get TFS to build/publish my web solution. I was able to get a build to complete successfully. adding msbuild argument /p:DeployOnBuild=True and setting the msbuild platform to x86 seemed to do the trick on that.
Then I found https://github.com/red-gate/deployment-manager-tfs which gives you a build process template to do the package and deployment using the redgate tools. After playing with that for a bit I finally got it to create, package and deploy my build to our staging environment.
Next up will be to modify the template to run some custom scripts to collect only the correct items to deploy, deploy all the sql files and then to set the workitems to the appropriate statuses after completion.
Really detailed description of your process. Thanks for sharing!
I believe you can set up TFS to have gated check-in on a single branch, which if you can setup on trunk would make sure that the merges built successfully. That could trigger msbuild, if you can get that working or a custom build job.
If you can get that working then you'd be able to use that trunk code as the artifact to send to Deployment Manager. That avoids having to assemble the files for deployment through the TFS change sets, as you'd be confident that the trunk could always build.
Are you using Deployment Manager to deploy the database from source control as well as the application?
That could be a way to further automate the process. SQL Source Control and SQL CI allow you to source control the structure of a database, keep a database up to date on each check-in, and run database unit tests. They also produce database packages for Deployment Manager, so you can deploy a release that contains both the application and the database.
If you want to send me the command you're using in step 4 to deploy the release using Deployment Manager I can help out with that. The commands I use are:
DeploymentManager.exe --create-release --server=http://localhost:81 --project="Project Name" --apiKey=XXXXXXXXXXX--version=1.1
DeploymentManager.exe --deploy-release --server=http://localhost:81 --project="Project Name" --apiKey=XXXXXXXXXXX--version=1.1 --deployto=CI-Environment-Name
That will create a release version 1.1 using the latest available packages for that project. You can optionally specify the package to be used when creating the release with
--packageversion=<package name>=<version>
--packageversion="application=1.5
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);