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.
Related
Forgive me for asking a stupid question. I am from IT Infrastructure background & have been asked to create CI/CD pipelines based on my recent learnings on DevOps.
We have couple of applications whose source code is currently in TFS 2013 & those apps are written in ASP.NET C# language. Now, requirement is to migrate the source code from TFS to Azure Repos (Azure DevOps services) & further create a CI/CD pipeline.
Now for demo purposes, customer is asking us to do the deployment (i.e. Release pipeline) on a test server which is a plain windows 2012 OS without any SQL & IIS for both of these applications. Is that possible & how could we achieve the results to confirm release pipeline is funcioning properly?
In my opinion, it wont work as there is no application infra/configuration done for those applications on that plain test server. I guess we actually need a ready dev/stage environment which is replica of production to do the testing of release pipeline for those applications. Am I correct?
Just need expert advise for confirmation so I communicate the same to customer.
Azure DevOps Pipelines use an agent to perform the deployments. You can run the agent entirely in the cloud when deploying to Azure resources. You can also install an agent locally. Follow this link and scroll down to read about self-hosted agents. This is how you can deploy to your test instance from the pipeline.
Now, what you deploy there may require additional software be installed. You say it's an application in C#. Cool. Now, what's it do? Is it a windows program? Then just having the server there, with an agent installed, is all you need. Is it a web program? Then, yeah, it's going to need an IIS (or whatever) instance available somewhere to deploy to. Is it a database program? Then, yeah, it's going to need a database instance to deploy to. There's nothing magical about having a VM or a machine somewhere. All the same rules have to apply. There has to be an OS, drives, memory, and yes, supporting services depending on the needs of the application.
However, using a local machine instead of a hosted one, that works fine. Just follow the instructions in the link above.
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.
I have been playing around with Visual Studio and Microsoft Release Manager. I have found a couple of behaviors I wasn't expecting and I was hoping someone might be able to confirm these (in case I'm getting the wrong end of the stick).
My goal is to:
Host my code in Visual Studio Online.
Deploy said code to on-premise or Azure hosted VM, using deployment agents.
My first attempt; using the Release Manager service provided as part of Visual Studio Online. However I found that I wasn't able to connect to Release Manager Online with agents deployed on-premise (or in Azure VMs).
I later found this text at https://www.visualstudio.com/en-us/get-started/release/manage-your-release-vs
You have the following options for managing your releases:
Using Release Management as a service on Visual Studio Online: You
need a Visual Studio Online account. You cannot use Chef and you can
deploy only to vNext environments based on Azure IaaS services
Using an on-premises server: You need to install Release Management
Server; do that here.
This seems to suggest that Visual Studio Online Release Manager cannot use agents - is this correct?
Assuming that is correct, my second attempt was installing Release Manager on-premises (so to speak, it is actually in an Azure VM).
I installed the latest RM versions (server, client, agent) from https://www.visualstudio.com/en-us/downloads/download-visual-studio-vs#d-release-management. Specifically, Release Management for Visual Studio 2013 with Update 4 (12.0.31101.0).
However I found that I was unable to connect the on-premise Release Manager to Visual Studio Online. The error message stating that I must supply the user name in 'domain\username' format - which won't match the online 'username#domain.com' format.
This seems to suggest that an on-premise installation of Release Manager cannot connect to Visual Studio Online - is this correct?
Thanks,
Okay, there are a few pieces of the puzzle here:
The Release Management client has to be on Update 4 (or later, when RM 2015 comes out later this year).
If you're using Visual Studio Online, on-prem Release Management cannot talk to it. It's a weird limitation, but there it is. You can hook the RM client up to RM Service in VSO, but that's it.
RM Service in VSO does not support deployment agents. It only supports "vNext" release templates, which operate off of PowerShell or DSC scripts to perform deployments.
Agents are, sadly, quickly becoming deprecated in favor of what's termed "agentless" or "vNext" deployments. Microsoft is currently working on totally revamping the Release Management piece, and the next version (which will be released in TFS 2015 Update 1) will not support agents at all.
If you want to use an on-prem RM server with VSO, you have to use RM without the TFS integration. It's still possible to get the bulk of the continuous delivery functionality, it just requires jumping through a few more hoops.
You'll have to set your components up as "builds externally" and use an on-prem build server
Your RM deployment agents in Azure (obviously) have to be able to talk to your RM server. This could require all sorts of firewall shenanigans, but that's a conversation to have with your networking folks.
If you want to do continuous delivery (where a build triggers a release), you'll have to look at the ReleaseManagementBuild.exe file (which is part of the RM client). This tool is responsible for launching releases as part of the build. The "Release" build process templates assume TFS integration, but the ReleaseManagementBuild.exe application has a "package" mode, where you can specify a UNC path to release. This gets you around not having direct TFS integration. It's possible to hack up the build process template a bit to take advantage of this.
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
Which one you choose?
Use the Deploy feature in VS
Build a rss script and execute it through rs.exe
Build a deployment package
Another option
Keep in mind that in many of your environments the report developers/designers don't have publish role in Reporting Server.
In Dev, we use the deploy feature in VS.
In Prod, our Prod support team will either upload them manually from the ReportServer website (if it's just one or two reports) or use a simple report upload utility that we wrote. The utility uses the SSRS web service.
For the developers we have a custom built ReportDeployer where we choose what environment to deploy to (development, test, production) and branch to deploy from (also development, test, production). There is a config file with all the reports available for deployment along with their directory structure. For production builds, the ReportDeployer has a command line interface and our build script pulls the latest reports from the Prod branch in TFS, then deploys all using our custom app.
Developers can publish to development using the deploy command in visual studio.
Admins move the reports from dev to prd with rsscripter.
We use rss scripts to get all reports from a folder and upload them to the given Report Server.