Answered by:
BizTalk application deployment to Production environment

Question
-
Hi All,
I am trying to understand the biztalk application deployment steps to Production environment so that the downtime is minimum or zero if possible. The infrastructure in question is as below.
The two DB server nodes can be active/passive. Kindly suggest. Thanks.
Ankur Seth
Monday, April 23, 2012 1:39 PM
Answers
-
Hi Ankur,
By being able to see the host instances on each BizTalk server it implies that they are load balanced, which is a form of HA clustering. When you select all hosts instances and restart them they are restarted one at a time ensuring little or no outage.
Regarding a zero outage deployment: Artifact versioning is the key. It's very powerful and essential for web-based development (with or without BTS) IMO.
The topic of versioning is too detailed to really cover here but have a look at the following to determine if it's a path you want to go down.
Some benefits/points re:versioning in BTS:
- It provides process isolation at all levels in the BTS architecture (at the gateway, process and pub/sub engine)
- It aligns your solution to the best practice of publishing schemas as web services (not orchestrations).
- You can deploy your artifacts without affecting long running processes
- Regression testing is reduced/eliminated
Some core implementation detail:
- Use schema versioning at the namespace and assembly level
- As above, publish schemas instead of orchestrations to the web. Publish your web service versions as websites on different ports
- your clients can migrate to the new version when THEY are ready
- this takes the pressure off you to release at the same time as your dependents - Make a decision to only support a certain number of service versions and deprecate older versions. When an interface is updated, upgrade it to the most recent version too.
- Version orchestrations (and subscriptions), maps and pipelines when appropriate - don't neglect reuse
As mentioned, the above just scrapes the surface when it comes to BTS SDLC management through versioning but have a look at the following links for some more information:
- Upgrading and Versioning Strategies for Applications
- Best Practices for Updating Applications
- Versioning Strategy for BizTalk Assemblies
If you do choose to go down the versioning path don't get caught up in the major, minor, revision, build decision process. I have found it much easier just to release a new major version of an assembly and use a _MMYY format for schema namespaces.
By separating your deployment from the runtime you can achieve your zero outage deployment but it takes planning.
Greg
- Marked as answer by LeoTangModerator Monday, May 7, 2012 6:39 AM
Tuesday, April 24, 2012 10:42 AM -
Hi Ankur,
I would suggest you to refer Recommendations for Installing, Sizing, Deploying, and Maintaining a BizTalk Server Solution technet wiki. It may answer all your queries.
HTH,
Naushad Alam
When you see answers and helpful posts, please click Vote As Helpful, Propose As Answer, and/or Mark As Answer
alamnaushad.wordpress.com
My new TechNet Wiki "BizTalk Server: Performance Tuning & Optimization"- Marked as answer by LeoTangModerator Monday, May 7, 2012 6:39 AM
Tuesday, April 24, 2012 6:58 PMModerator
All replies
-
Hi
My views are below on this:
Full Deployment- For me it would mean, Delete the BizTalk application and create the application,deploy all the assemblies in GAC and Import all the BizTalk artifacts like schema/map/orchestration/rules/bindings to BizTalkMgtDatabase.
For this
1- Application downtime will be required.
2- Application will be deleted from BizTalkMgtDatabase
3- Either BizTalk1/2 will be used to create the application and deploy all the BizTalk binaries to BizTalkMGTDatabase
4- All the binaries will be gac'ed on BizTalk Server2.
5- If you are using Web Services, They will be deployed on both the BizTalk servers and AppPool Reset will be required.
6- Host instance on all the servers related with your application will be required to recycle to take the latest changes of assemblies and configuration.Incremental Deployment- This again depends upon no of changes and the related components. If its just a configuration change then you would need a host instance restart.
Also if its a change in the DLL then Host instance restart is required on both the biztalk servers. But the application downtime will be less in this case.I hope this helps!
HTH,
Naushad Alam
When you see answers and helpful posts, please click Vote As Helpful, Propose As Answer, and/or Mark As Answer
alamnaushad.wordpress.com
My new TechNet Wiki "BizTalk Server: Performance Tuning & Optimization"Monday, April 23, 2012 1:52 PMModerator -
Hi Naushad,
I have one question. Why I need to delete the BizTalk application. I mean, we can stop the host instance and run msi to import the changes. Is there are a possiblity that this could lead to some of the dlls not getting updated/GAC correctly.
I agree that we can't have zero downtime. Also, how about if we are depenedent on third party to update changes. How, should third party changes be sync?
Thanks.
Ankur Seth
Monday, April 23, 2012 2:02 PM -
Hi
You could do that, but I like to make it clean every time.
- Remove everything from GAC
- Remove the resoruces from BizTalk app
- Delete the App
- Create the APP
- Add Resoruces
- Add DLLS in GAC
- Import the bindings
Reg Third party changes, You would need to have a proper implementation plan agreed with your third party and you have to perform the changes in agreed controlled way.
HTH,
Naushad Alam
When you see answers and helpful posts, please click Vote As Helpful, Propose As Answer, and/or Mark As Answer
alamnaushad.wordpress.com
My new TechNet Wiki "BizTalk Server: Performance Tuning & Optimization"- Edited by Naushad.AlamModerator Monday, April 23, 2012 5:26 PM
- Proposed as answer by Naushad.AlamModerator Thursday, May 3, 2012 7:22 PM
Monday, April 23, 2012 3:07 PMModerator -
Hi Ankur,
There is insufficient information about your BTS application architecture in your question but if we assumed a couple of things:
- that your inbound BizTalk interfaces were 100% web service based; and
- the application load balancer was a hardware appliance or software based NLB;
you could actually achieve zero downtime if you version your interfaces and artifacts correctly.
Is this the case? Are your inbound interfaces all web based?
Greg
Tuesday, April 24, 2012 9:24 AM -
Hi Greg,
Both your assumptions are correct. Also one more point, the hosts are not clustered but you can see the host instance of each server node on other server as the BizTalk application servers share the same DB.
Thanks.
Ankur Seth
Tuesday, April 24, 2012 9:28 AM -
Hi Ankur,
I would prefer to undeploy and deploy fresh copy with minimum downtime. This method will guarantee that you have new dll's in place.
If you do import MSI , I am sure you will end up with referring old Schemas/orchestration. etc issues at runtime and you may need to do another round of deployment. - It happened to me couple of times.
Raj, http://rajwebjunky.blogspot.com
Tuesday, April 24, 2012 9:47 AM -
Hi Ankur,
By being able to see the host instances on each BizTalk server it implies that they are load balanced, which is a form of HA clustering. When you select all hosts instances and restart them they are restarted one at a time ensuring little or no outage.
Regarding a zero outage deployment: Artifact versioning is the key. It's very powerful and essential for web-based development (with or without BTS) IMO.
The topic of versioning is too detailed to really cover here but have a look at the following to determine if it's a path you want to go down.
Some benefits/points re:versioning in BTS:
- It provides process isolation at all levels in the BTS architecture (at the gateway, process and pub/sub engine)
- It aligns your solution to the best practice of publishing schemas as web services (not orchestrations).
- You can deploy your artifacts without affecting long running processes
- Regression testing is reduced/eliminated
Some core implementation detail:
- Use schema versioning at the namespace and assembly level
- As above, publish schemas instead of orchestrations to the web. Publish your web service versions as websites on different ports
- your clients can migrate to the new version when THEY are ready
- this takes the pressure off you to release at the same time as your dependents - Make a decision to only support a certain number of service versions and deprecate older versions. When an interface is updated, upgrade it to the most recent version too.
- Version orchestrations (and subscriptions), maps and pipelines when appropriate - don't neglect reuse
As mentioned, the above just scrapes the surface when it comes to BTS SDLC management through versioning but have a look at the following links for some more information:
- Upgrading and Versioning Strategies for Applications
- Best Practices for Updating Applications
- Versioning Strategy for BizTalk Assemblies
If you do choose to go down the versioning path don't get caught up in the major, minor, revision, build decision process. I have found it much easier just to release a new major version of an assembly and use a _MMYY format for schema namespaces.
By separating your deployment from the runtime you can achieve your zero outage deployment but it takes planning.
Greg
- Marked as answer by LeoTangModerator Monday, May 7, 2012 6:39 AM
Tuesday, April 24, 2012 10:42 AM -
Note also that the BizTalk Deployment Framework http://biztalkdeployment.codeplex.com/ has good support for versioned deployments.Tuesday, April 24, 2012 1:46 PM
-
Hi Ankur,
I would suggest you to refer Recommendations for Installing, Sizing, Deploying, and Maintaining a BizTalk Server Solution technet wiki. It may answer all your queries.
HTH,
Naushad Alam
When you see answers and helpful posts, please click Vote As Helpful, Propose As Answer, and/or Mark As Answer
alamnaushad.wordpress.com
My new TechNet Wiki "BizTalk Server: Performance Tuning & Optimization"- Marked as answer by LeoTangModerator Monday, May 7, 2012 6:39 AM
Tuesday, April 24, 2012 6:58 PMModerator