Transcript Build Server - Biztalkusergroup.se

Application Lifecycle
Management
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?
Business
critical
solutions.
Complex
solutions from
a technical
perspective.
Changes need
to be
controlled
and
reversible.
Complex
solutions from a
organizational
perspective.
What can you expect today?
Our
humble
opinions.
Can we reach 80 %
with 20 % effort?
No silver bullet,
there are many
ways to skin a
cat.
Automated tests
Code workflow
Fix it!
Unit test
Three days later
Value
Ok! I’ll get to
work!
Integration
test
BOOM
Stop everything!
And fix this.
Packaging and reference management
Work
Continuous Integration workflow
Code workflow
Distributed version control is easy ...?
CVCS - Subversion
• One shared central repository
• When you check in code,
everybody else gets it
http://hginit.com/
Problems with CVCS
• 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?
Changes
Commit
buggy
code
Avoid
checking
in
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/
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
Git and Visual Studio
• Visual Studio update 2 required
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!
Add logic to handle
additional costs
master
Ok! I’ll get to work!
Customer
Making change in branch ”dev1/AddAdditionalCost”
Creates
dev1/addadditionalcosts
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
Dev1
Dev2
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
Questions and comments: Code workflow
Automated
Testing
”Integration tests” vs. ”Unit tests”
Application
Component A
Unit tests
Integration tests
Component B
Component C
”Integration tests” vs. ”Unit tests” in BizTalk
Server
Receive
Send
BizTalk Server Engine
Dlls
Integration tests
Unit tests
Schemas
Orchestrations
Transformations
Pipelines
Other
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
Unit testing pipeline
components
Problems
IBaseMessage
• Lives inside a pipeline
IPipelineContext
• IBaseMessage and IPipelineContext
• Often has a lot of pre-conditions
• Annoying build-deploy-test-bounce cycle
Component1
Component to test
Component2
Component3
Component4
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
• https://github.com/tomasr/pipelinetesting/blob/master/Winterdom.
BizTalk.PipelineTesting.Tests/Simple/PipelineUsageTests.cs
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
Questions and comments: Automated
testing
Packaging and
dependency
management
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.
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
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
What if…
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…
Is NuGet the solution?
• …NuGet does not support btproj projects
• nuget.codeplex.com/SourceControl/network/forks/robinhultm
an/NuGetWithBizTalkProjectExtension/contribution/5960
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
Dev1
Change to shared
solution
Shared EDI
Schema Solution
CustomerInvoice
Solution
Dev2
Shared EDI
Schema Solution
CustomerInvoice
Solution
Source control
server
Azure
Build server
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.
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!
Questions and comments:
Packaging and dependency management
Continuous
Integration
What’s Continuous
Integration/delivery/deployment really?
Compile
Test
Source control
server
Developers
Build server
Package
Version/
label
Dlls
Deployment
area
Automated
deployment
BizTalk Server
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 changes out early, no big bang deployment
Continuous
Integration/delivery/deployment in BizTalk
Sweet spot!
2. This is usually
tricky in a BizTalk
solution …
1. Here we want a
deployable
package
3. Traditionally we
had to install in a
server before we
could get a
deployable
package.
Deployment Framework for BizTalk is an
option
1.
Deploy a complex solution containing
orchestrations, schemas, maps, rules,
custom components, pipeline components,
pipelines -- even ESB itineraries -in minutes, with no human intervention
2. Eliminate ALL manual steps in your BizTalk
deployments
3. Consolidate all of your environmentspecific configuration and runtime settings
into one, easy-to-use Excel spreadsheet
4. Maintain a SINGLE binding file that works
for all deployment environments
5. 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!
Can we reach our “sweet spot” Continuous Delivery - without installation?
Option 1
BTDF
BTDF/BTS task
Automated
installation
Export MSI
Build Server
Compile
Dlls
Option 2
BizTalk Server
BtsMsiTask
Build Server
Compile
Export MSI
Dlls
MSI
MSI
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
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 
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
Questions and comments:
Continuous Integration
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.