1. Application Lifecycle Management
Sort of … From a technical
BizTalk perspective ;)

2. Who are we? Robin Hultman Solution Architect at iBiz Solutions
Richard Hallgren
Solution Architect at iBiz Solutions

3. What’s ALM?

4. Why is ALM important in a BizTalk context?
Business critical solutions.
Changes need to be controlled and reversible.
Complex solutions from a technical perspective.
Complex solutions from a organizational perspective.

5. What can you expect today?
Our humble opinions.
No silver bullet, there are many ways to skin a cat.
Can we reach 80 % with 20 % effort?

6. Packaging and reference management Continuous Integration workflow
Fix it!
Ok! I’ll get to work!
Three days later
Stop everything! And fix this.
BOOM
Code workflow
Work
Value
Integration test
Unit test
Automated tests
Packaging and reference management
Continuous Integration workflow

7. Code workflow

8. Distributed version control is easy ...?

9. CVCS - Subversion One shared central repository
When you check in code, everybody else gets it

10. Problems with CVCS Do you write perfect code the first time?
Changes
Commit buggy code
Avoid checking in
Do you write perfect code the first time?
New code is buggy
Fear of checking in
Why have version control if you can’t use it?

11. DVCS - Git Every developer has their own private repository
Commit whenever you like
Push changes to central repository when it’s ready.
Separates the act of committing new code from the act of inflicting it on everybody else

12. The dreaded merge Subversion thinks about revisions
OK, I have version 1. And now I have version 2. And now I have version 3
Git thinks about change sets
I had nothing. And then I got these changes. And then I got these other changes.
So what is the difference?
When it comes to merge Git knows a lot more about what we have done than Subversion
Feel free to branch because merge isn’t going to be a nightmare
Keeping stable and dev code separate is what source control is all about

13. Git and Visual Studio
Visual Studio update 2 required

14. Demo: DVCS Workflow This is what you’ll see
A typical code workflow with an ongoing change from one developer (dev 1), while an other developer (dev 2) has to fix a critical bug, in the same solution!

15. Add logic to handle additional costs
master
Add logic to handle additional costs
Ok! I’ll get to work!
Customer
Dev1
Dev2
fix in master
Creates dev1/addadditional-costs
Making change in branch ”dev1/AddAdditionalCost”
Critical bug!
Merges dev1/additional-costs to master
We’ll fix it at once!
Fix the bug. It’s prioritized!
Fixing bug in directly in master
Bug fixed and deployed!
Great. The Additional cost fix is tested and ready for prod
Great. I’ll make a deployment package!
Merge additional cost fix to master for deployment

16. Takeaways: Code workflow
A DVCS makes it possible to commit new code with out stepping on everybody's toes
In a DVCS branching and merging actually works …
A local repository is powerful once one gets the hang of it
Git and DVCSs has a learning curve

17. Questions and comments: Code workflow

18. Automated Testing

19. ”Integration tests” vs. ”Unit tests”
Application
Component A
Component C
Component B
Unit tests
Integration tests

20. ”Integration tests” vs. ”Unit tests” in BizTalk Server
BizTalk Server Engine
Receive
Send
Integration tests in BizTalk requires all artifacts to be installed on the server!
Remember
Hard to pinpoint the error once test fails.
Require fully automated installation on build server to work – on each test run!
Integration tests
Dlls
Transformations
Schemas
Orchestrations
Pipelines
Other
Unit tests

21. Demo: Unit test map This is what you’ll see
Use BizTalk Servers built-in features to test maps
Expose a few interfaces to interact with the artifact from test tool
Use MsTest to execute the tests

22. Unit testing pipeline components

23. Problems Lives inside a pipeline Often has a lot of pre-conditions
Component1
Component2
Component3
Component4
IBaseMessage
IPipelineContext
Component to test
Lives inside a pipeline
IBaseMessage and IPipelineContext
Often has a lot of pre-conditions
Annoying build-deploy-test-bounce cycle

24. Demo: Unit test pipeline component This is what you’ll see
Utility classes for creating IBaseMessage from XML string
Pipeline wrappers to set pipeline context
Enables debugging of component without deployment
BizTalk.PipelineTesting.Tests/Simple/PipelineUsageTests.cs

25. Takeaways: Automated testing
Keep it simple stupid – unit test takes us far!
Enables testing from build server and directly from Visual Studio with minimal effort – without any installation. Quickly becomes important part of development workflow.
Test logic and code directly without testing framework code
Easy to isolate tests and logic and pinpoint failing tests

26. Questions and comments: Automated testing

27. Packaging and dependency management

28. Why is there so many dependencies?
BizTalk Server solutions typically include artifacts like schemas, maps, pipelines and orchestrations.
When it comes to grouping these artifacts into assemblies we want them to be:
Small and easy to deploy
Reusable when possible
Logically related
 When one artifact needs to use another artifact, it is said to be dependent on that artifact.
If the artifacts are located in different assemblies, we have an assembly reference.

29. Challenges – a developer’s perspective
Assembly references needs to be satisfied before we can build
Hopefully the dependencies are properly documented
Trial and error
How can we share components?
Hard to target a specific version of a shared resource
Build all dependencies
Build initial project
Build initial project

30. What if… Only need a binary for all references
Publish shared assemblies as part of the build process to a designated deploy area
Automatically resolving references

31. What if…

32. Is NuGet the solution?
NuGet is a package manager for the Microsoft developer platform
Can create NuGet-packages from assemblies
NuGet packages can be published to a feed server
Developers can browse and download NuGet packages in Visual Studio
Packages are versioned
Visual Studio can automatically resolve and restore references to packages
A NuGet feed can be private or public.
Only one problem…

33. Is NuGet the solution? …NuGet does not support btproj projects
nuget.codeplex.com/SourceControl/network/forks/robinhultm an/NuGetWithBizTalkProjectExtension/contribution/5960

34. Demo: NuGet packaging of BizTalk artefacts This is what you’ll see
How we can package a shared BizTalk Schema in NuGet package
How we can use the NuGet package to solve a needed dependency on one of our solutions
How a version updates of dependencies are handled and managed using NuGet

35. Azure Shared EDI Schema Solution Source control server Build server
CustomerInvoice Solution
Dev1
Azure
Build server
Source control server
Change to shared solution
Dev2
CustomerInvoice Solution
Shared EDI Schema Solution

36. Demo: NuGet packaging of BizTalk pipeline components This is what you’ll see
How we can package a pipeline component as a NuGet package.
How we can use the NuGet package to solve a needed dependency on one of our solutions.

37. Takeaways: Packaging and dependency management
Dependency management in BizTalk is a small problems but can be tricky enough on a build server – NuGet offers a nice solution to the problem
Sharing of pipeline components is important to not reinvent the wheel over and over
NuGet has a nice solution to versioning!

38. Questions and comments: Packaging and dependency management

39. Continuous Integration

40. What’s Continuous Integration/delivery/deployment really?
Developers
Source control server
Build server
Compile
Test
Package
Version/
label
Dlls
Deployment area
Automated
deployment
BizTalk Server

41. Why bother using CI etc? Continuous Integration Continuous Delivery
All build code is actual check-in code in source control.
Code has been build on a machine with no special settings or dependencies – ”it works on my machine”
All build are versioned and labeled
Continuous Delivery
All packages are stored in one common area and one can always roll back to previous versions
Always has ready-to-go packages for new or recovered environments
Continuous Deployment
Can save a lot of installation time ;)
Get small changes out early, no big bang deployment

42. Continuous Integration/delivery/deployment in BizTalk
3. Traditionally we had to install in a server before we could get a deployable package.
Sweet spot!
2. This is usually tricky in a BizTalk solution …
1. Here we want a deployable package

43. Deployment Framework for BizTalk is an option
Deploy a complex solution containing orchestrations, schemas, maps, rules, custom components, pipeline components, pipelines -- even ESB itineraries -- in minutes, with no human intervention
Eliminate ALL manual steps in your BizTalk deployments
Consolidate all of your environment- specific configuration and runtime settings into one, easy-to-use Excel spreadsheet
Maintain a SINGLE binding file that works for all deployment environments
Make automated deployment a native part of the BizTalk development cycle, then use the same script to deploy to your servers
Bonus Reason: It's free!
PowerShell and MSBuild are fun too! 

44. Automated installation
Can we reach our “sweet spot” - Continuous Delivery - without installation?
Option 1
MSI
Build Server
BizTalk Server
Compile
Dlls
Automated installation
Export MSI
BTDF
BTDF/BTS task
MSI
Build Server
Compile
Dlls
Export MSI
BtsMsiTask
Option 2

45. Demo: BtsMsiTask and TFS This is what you’ll see
Build a MSI directly from Visual Studio without any installation in BizTalk Server using BtsMsiTask and MSBuild
Execute BtsMsiTask as part of a TFS build

46. Bonus demo: BtsMsiTask and TeamCity This is what you’ll see
We do as the NuGet team and show you how it’s done in TeamCity 

47. Takeaways: Continuous Integration
CI is an important pattern to develop and maintain high quality software over time in teams
CI can be hard to do with BizTalk Server but there are tricks that will help you to keep it simple – and still get you a lot of value

48. Questions and comments: Continuous Integration

49. Final thoughts
Again, it all our opinions – different solutions for different needs.
A workflow and build solution needs to be simple – the actual solution usually gets complicated enough!
One can get far using unit tests and simple Continuous Integration and Continuous Delivery.