1 / 0

Application Lifecycle Management

Application Lifecycle Management. Sort of … From a technical BizTalk perspective ;). Who are we?. Robin Hultman Solution Architect at iBiz Solutions. Richard Hallgren Solution Architect at iBiz Solutions. What’s ALM?. Why is ALM important in a BizTalk context?.

tadeo
Download Presentation

Application Lifecycle Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Application Lifecycle Management

    Sort of … From a technical BizTalk perspective ;)
  2. Who are we? Robin Hultman Solution Architect atiBiz 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. Automated tests Code workflow Fix it! Ok! I’ll get to work! Unit test Integration test Value BOOM Three days later Stop everything! And fix this. Work 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 http://hginit.com/
  10. Problems with CVCS Changes 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? Commit buggy code Avoid checking in
  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 http://hginit.com/
  12. The dreadedmerge 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 WorkflowThis 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 Ok! I’ll get to work! Customer Dev1 Dev2 Creates dev1/addadditional-costs Making change in branch ”dev1/AddAdditionalCost” Critical bug! Fix the bug. It’s prioritized! We’ll fix it at once! Fixing bug in directly in master fix 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 Merges dev1/additional-costs to master
  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 B Component C Unit tests Integration tests
  20. ”Integration tests” vs. ”Unit tests” in BizTalk Server BizTalk Server Engine Remember Integration tests in BizTalk requires all artifacts to be installed on the server! Hard to pinpoint the error once test fails. Require fully automated installation on build server to work – on each test run! Receive Dlls Send Schemas Orchestrations Transformations Pipelines Other Integration tests Unit tests
  21. Demo: Unit test mapThis 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 Component1 IBaseMessage Lives inside a pipeline IBaseMessage and IPipelineContext Often has a lot of pre-conditions Annoying build-deploy-test-bounce cycle IPipelineContext Component2 Component3 Component to test Component4
  24. Demo: Unit test pipeline componentThis 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 https://github.com/tomasr/pipelinetesting/blob/master/Winterdom.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 manydependencies? 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. Whatif… 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. Whatif…
  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/robinhultman/NuGetWithBizTalkProjectExtension/contribution/5960
  34. Demo: NuGet packaging of BizTalk artefactsThis 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. Dev1 Shared EDI Schema Solution Source control server Build server Change to shared solution Azure CustomerInvoice Solution Dev2 Shared EDI Schema Solution CustomerInvoice Solution
  36. Demo: NuGet packaging of BizTalk pipeline componentsThis 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? Compile Test Developers Source control server Build server Package Version/ label Dlls Deployment area Automated deployment BizTalk Server
  41. Why bother using CI etc? Continuous Integration 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 changesoutearly, 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. Can we reach our “sweet spot” - Continuous Delivery - without installation? BTDF/BTS task Option 1 BTDF Build Server Dlls BizTalk Server MSI Automated installation Export MSI Compile BtsMsiTask Option 2 Build Server Dlls MSI Export MSI Compile
  45. Demo: BtsMsiTask and TFSThis 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 TeamCityThis 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 solutionsfor 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.
More Related