I want to make a multi deployment server using the "Deploy BizTalk Application" task on azure release pipeline from a deployment group job, but the task install all the artifacts (add resources, GAC, bindings) on the 3 servers . is there a way to limit the bindings and adding resources only on the first node?
the current behaviour generate an exception :
Concurrency Violation encountered while Updating
Other thing, in BizTalk 2016 FP2 MSFT has added an enhancement for deployment group, someone knows what is really changed?
This is going to be a long post, so hang on.
You want to learn about BTDF (BizTalk Deployment Framework). I wrote a whole guide for my internal team, so I cannot share that easily. But I'm going to try to explain what you need to do.
1) In our Azure DevOps organization, add the extensions "Deployment Framework for BizTalk" and "BTDF Project Updater" (I wrote that one, but is optional to update the version number for the generated MSI).
2) There are guides online, but learn how to make your project into an MSI and deployable using the BTDF within the Build Pipeline. Leverage "BTDF Project Updater" to increment the version number.
3) Now, you said you have 3 servers within your BizTalk environment. During a manual BizTalk deployment Server 1 and Server 2 get a "light" BizTalk deployment and Server 3 gets the FULL BizTalk deployment. This means during the Release Pipeline to do a release on Servers 1 and 2, but do it a tiny bit different on Server 3.
3.1) Create a normal Agent Pool for Server 3, and associate the ADO Agent on Server 3 to that.
3.2) Create a Deployment pool and associate the agents for Server 1 and Server 2 (I think you've done that already)
4) Create your Release Pipeline for that particular environment, but we are going to put in 2 Agent phases instead of the default 1. Notice that I am using different types of agent jobs for the pools created above.
For the Release Pipeline tasks for each agent I just happen to be using a task group template because I have any release pipelines. I have one called "Standard Deployment - Not Final" and one called "Standard Deployment" (which is the final). WHY? BizTalk requires application binaries and certain other artifacts to be installed on every BizTalk server that runs the application. However, the BizTalk application, its port bindings, rule policies and more must be registered in the BizTalk databases only once within the group. This is the reason for the checkbox. Notice it is unchecked for the "Not Final" and checked for the one that will be the "Final". The installation will go very quickly on Servers 1 and 2, but take longer on Server 3 because of this.
Now you can start your ADO Release Pipeline to test it out. But this process work great and I'm using it in conjunction with GitVersion.
I know I left a lot out of this guide, like the actual details of the tasks for stopping the BizTalk app via the PS script, UnDeploying the BizTalk app, unInstaling the MSI, why am I copying the MSI to the installation directory, and then install. You can read more from the official documentation here: http://www.tfabraham.com/BTDFDocs/V5_5/DeploymentFrameworkForBizTalkDocs.html?DeployConfigurationSettingsintoS.html
I hope this helps!
Related
If we are deploying a basic WebApp / WebApi, both these tasks from Microsoft appear to do the same thing - deploy to an appservice.
AzureWebAppV1
AzureRmWebAppDeploymentV4
How do you choose which one to use in a new YAML release pipeline? I just want to make sure I am using the version that is most future-proof - I have 25 release pipelines and don't want to have to re-do them unless necessary.
The way the help is written, hard to compare feature to feature to spot the key "must-haves". Some Microsoft online examples use both. Both are still marked as "In Development" in the readme and both are >1 year old since last check in.
The simplest way to deploy to an Azure Web App is to use the Azure Web App Deploy (AzureWebApp) task.
By default, your deployment happens to the root application in the Azure Web App. You can deploy to a specific virtual application by using the VirtualApplication property of the AzureRmWebAppDeployment task.
Azure App Service Deploy task allows users to modify configuration settings in configuration files (*.config files) inside web packages and XML parameters files (parameters.xml), based on the stage name specified.
Just my two cents, but I just noticed Web App Deploy takes much less time than Service App Deploy. I was wondering how come a simple zip deploy (Service App Deploy) can take so long. So I looked around and found there's also that Web App Deploy, so I tested it.
My project (React/Next small sized app) normally takes 6-10 min to deploy with Azure Service App Deploy (v4). With Azure Web App Deploy (v1) it took a little more than a minute. Wow.
Similar questions have been asked various times, but most answers are old and may only partially apply. This question is specific to using Web Deploy through Azure DevOps/Azure Pipelines using the "Azure App Service Deploy" task, version 3.*.
Failed to deploy web package to App Service.
Try to deploy app service again with Rename locked files option selected.
Error Code: ERROR_FILE_IN_USE
More Information: Web Deploy cannot modify the file 'VBCSCompiler.exe' on the destination because it is locked by an external process. In order to allow the publish operation to succeed, you may need to either restart your application to release the lock, or use the AppOffline rule handler for .Net applications on your next publish
attempt. Learn more at:
http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.
There's two recommendations there:
Select "Rename locked files" option
Restart the application
Use the AppOffline rule
Additionally, the documentation for the task reiterates recommendations 1 and 3 together.
For avoiding deployment failure with error code ERROR_FILE_IN_USE, in case of .NET apps targeting Web App on Windows, ensure that 'Rename locked files' and 'Take App Offline' are enabled. For zero downtime deployment use slot swap.
However, these recommendations are already in place.
All that's left is recommendation 2: restart the service. For many reasons, I rather not have to fall back to this.
Why are 1 and 3 not enough to complete the deployment successfully?
I spoke with a Microsoft support rep and was told that "Rename locked files" only works for DLLs.
But I did find a solution that did work for me. In "Additional arguments", I added "-useChecksum". So the "Deploy Azure App Service" task now looks like this
I haven't had any problems since.
There is an issue tracked here : Azure App Service Deploy fails for .net core 2.0 with ERROR_FILE_IN_USE and based on vincentdass's comment "PR #8457 for consuming new version of MSDeploy as per Web Deploy team recommendation." There will be an upgrade for msdeploy in future version.
However you can just checking Publish Using Web Deploy and Rename Locked Files, then creating a new deployment. Redeploy won't work because it won't pick up your changes to the release definition.
Reference below thread, you can check the discussion about this issue and troubleshoot accordingly.
Azure App Service Deploy fails for .net core 2.0 with
ERROR_FILE_IN_USE
I have installed TFS 2018 and I'm trying to setup dedicated build server for this.
I have three windows servers one for TFS-WindowsBox1(TFS 2018 Installation completed), one for Build server-WindowsBox2(Build server setup steps and architecture needed), DB-WindowsBox3(DB Installation completed).
I'm looking for build server setup on WindowsBox2 and I'm looking best practices or steps to follow.
In administration section, I'm seeing agent download option in agent pools tab.
If i download and install agent on windowsbox2 server , will that be considered as Build server.
And what are the differences between agents and build server setup ?
TFS has no concept of a "build server". If an agent is configured on a box and the agent is running, then that box can run builds (and releases, since the release agent is the same piece of software). That's all there is to it. Build agents are assigned to agent pools, which dictate the set of available agents.
In previous iterations of the build system (XAML build, TFS 2010 - TFS 2013, although it's configurable up to TFS 2018), you had to register build controller and assign build agents to the build controller. XAML build is deprecated and should not be used except in the cases of pre-existing legacy builds, so if you're not already using XAML build, you can safely ignore this paragraph.
You can refer to this article (Deploy an agent on Windows) to setup TFS build/release agent, after that this is your "build server".
There are interactive and service mode and by default it is running in interactive mode, for this mode, you need to call run.cmd (in the same folder of config.cmd) to start agent, then the agent state will be online.
With service mode, you can check whether the corresponding service is running or not in Services.
I'm setting up a build definition in Visual Studio Team Services using a Build Agent installed on my local machine for testing.
I'm following these instructions for creating a build agent, setting up a build definition, and queuing a build. I've created the agent on my local computer and it appears in the agent pool in VSTS. The agent is enabled and ready to go. I've also created a build definition that invokes my build script. Everything up to this point appears to work fine.
At this point I'm ready to queue a build and run it. The dialog for this looks like:
The dropdown labeled "Queue" only shows the Hosted agent pool. There should be a second pool called Default but it is not appearing. I can get it to "appear" by right clicking and inspecting the HTML and then using dev tools to change the value for the Hosted option. Hosted's ID is 2, I changed it to 1 since I assumed this to be the ID for Default. Once I do this I can click "OK" and the build runs as expected -- everything is checked out on my local machine by the build agent. Presumably my assumption about the ID value is correct.
So...everything it working correctly once I muck around with the plumbing a bit. But this is definitely not the way things should be working. Why is the Default queue not showing up in the dropdown? Do I need to flip a switch somewhere to make it work? Does my account not have enough access?
Some other details:
My account is a "Pool Administrator"
The build agent is not installed as a Windows service. I start it manually from a command prompt. I've not been able to install it as a service.
The machine that has the build agent installed on it is running Windows 10 x64 Pro. It was upgraded from Windows 8 x64 Pro.
I cannot use a hosted agent as I'm building a Unity project and Unity is not supported by for hosted agents.
I know I can use Unity Cloud Build but I do not want to.
UPDATE
I've removed my previous Build Agent and installed a new one, as a service, on a Windows Azure VM running Windows 10 Enterprise x64. With this change the "Hosted" and "Default" queues are appearing as expected.
Your account needs to also have access to the agent queue. Agent pools and agent queues are different entities, and being a "pool administration" does not necessarily mean you are a "queue administrator".
In my case it helped to execute the agent configuration in a console with elevated/administrator rights. If the agent configuration is done in a console with normal rights, the agent can still be configured properly, but its queue won't appear for selection when you will be queuing a new build.
Just went from TFS 2008 to 2010 at a client site and now wondering what happened to the TFSBuild.proj files from the TeamBuildTypes folder. I've already got the builds and drops working and now I need to get the old deployments working again. We used to do this with AfterBuild targets in the TFSBuild.proj. That mechanism seems to have moved or disappeared in 2010.
Can anyone point me to an article or describe how the deployment options have changed in 2010?
Specifically, I need to support running psexec to install and enable Windows Services on remote deployment targets and I need to deploy some web sites / web services to remote IIS nodes as part of the automated builds.
EDIT: Just found this: http://blogs.msdn.com/jimlamb/archive/2009/11/03/upgrading-tfs-2008-build-definitions-to-tfs-2010.aspx I'm more than a little taken back by the breaking changes between 2008 and 2010. I'm gonna need advice on how to deploy remote sites and services in the new default build process template mechanism.
Check out Vishal Joshi's PDC talk on Deploying Web Applications with VS 2010 and MSDeploy. On his blog, you'll also find tips on building MSDeploy packages with MSBuild. You can run psexec from your MSBuild script or, potentially, from a customized build process template. With TFS 2010, you can use MSBuild and Windows Workflow to solve your build automation problems.
Alternatively, you can use the "Upgrade" build process template and continue using your TFSBuild.proj file. This is the default behavior for upgraded build definitions for backwards compatibility. In that case, your build is still primarily driven by MSBuild with just a thin workflow to allocate an agent and run MSBuild.
Another option is to use TFS 2010 Build Agent on the server that you deploy to. This is how Visual Studio Lab Management deploys.
I have written a blog post about this: Continuous deployment with TFS 2010 Build Agent