Presentation on how to deploy applications directly from TFS Builds.

1. Ricci Gian Maria
Alkampfer@nablasoft.com
@alkampfer
http://www.codewrecks.com/
http://www.getlatestversion.it/author/alkampfer/
http://blogs.ugidotnet.org/rgm
How to deploy .NET
applications with TFS Build
ALM Deep dive with TFS 2013
#vsalmdeep

2. Session Lineup
Deploy or Release??
Why TFS Build
Continuous deployment
Deploy Web Applications
What about my Sql Server Database?
And for other type of Applications (non web)?
#vsalmdeep

3. Event Sponsor
#vsalmdeep

4. Deploy or Release?
#vsalmdeep
 Deploy
 The act of installing software in a set of computers
 Does not requires accounting or ownership
 Release
 The act of making software available downstream
 Monitored and repeatable process
 Multi-stage process

5. Why continuous deployment?
#vsalmdeep
 No error made by manual procedures
 Is a good deploy documentation
 Consistent
 Repetable
 Automated
 Verified and testable

6. TFS Build or….
#vsalmdeep
TFS
Build
Agent Environment

7. Release Management?
#vsalmdeep
TFS Build Package
RM

8. Why using Build?
#vsalmdeep
 Pro
 No additional cost or license
 Simpler to setup
 Already in place for CI
 Cons
 Lesser pre-built actions
 Does not support pipelines
 Push process instead of pull process

9. What is behind Azure publising?
#vsalmdeep
 Lots of options
 We will focus on VSO/TFS integration

10. DEMO
Deploy to Azure Web Site
#vsalmdeep

11. What is behind Azure publising?
#vsalmdeep

12. What is behind Azure publising?
#vsalmdeep
VSO/TFS Build
agent
Azure Web
Site

13. Why Vso and not Git/dropbox/…?
#vsalmdeep
 Automatic trigger (scheduled, each check-in, gated
check-in, etc)
 Fully extensible as every build
 Centralized log
 Binary in Drop folder
 Publishing of Symbol Source
 Integrated with all TFS World (es: feedback tool)

14. What about on-premise?
#vsalmdeep
 All combinations of infrastructure are possible
 VSO + Elastic Build + Azure site (default)
 VSO + Build on premise + Azure Web Site
 TFS and Build on premise + Azure Web Site
 VSO + Build on premise + local IIS web site
 TFS and Build on premise + local IIS web site

15. DEMO
Change build to publish to IIS
#vsalmdeep

16. What about my sql server DB?
#vsalmdeep
 Sql Server (and all SQL) bring some pain for deploy
 Store latest schema changes with code (source
controlled)
 Verify new schema is valid before deployment
 Update an existing database with latest schema
without touching data
 Deploy the schema even if someone had made
manual changes from last deploy
 Deploy some static data in certain tables
 Ensure some test data for test environments

17. Database projects to the rescue
#vsalmdeep
 A db project uniforms database development to
normal code development
 A single project in visual studio
 Compile to Data-tier application and Deployable
Build agent
DAC

18. DEMO
Deploy with Database projects
#vsalmdeep

19. Fail as soon as possible
#vsalmdeep
 Minimize time from when a bug is introduced in code
to the time this bug is discovered
 Fail as soon as possible
 You need automatic testing
 Unit test
 Integration test
 Performance test
 User acceptance test
 etc

20. What to test?
#vsalmdeep
 Integration, performance, acceptance test need full
test environments
 Continuous deployment helps to keep these
environments aligned with latest bits
 You can run Automatic Tests against these
environments to immediately detect problems in
software.

21. DEMO
Build – deploy – performance test with TFS and
VS web performance tests
#vsalmdeep

22. Click-once
#vsalmdeep
 Standard desktop application can be published with
click once
 Build should be customized at least in two points
 Before the build takes place
 generate assembly file number incrementally
 After the build takes place
 publish click once application locally in the build
server
 Use mage.exe to modify publish (optional)
 Move published file in the definitive location

23. DEMO
Deploy click once application using console
application
#vsalmdeep

24. Nuget packages
#vsalmdeep
 Private or public nugget servers are exceptional to
share common dll
 Build should be customized at least in two points
 Before the build takes place
 generate assembly file number incrementally
 After the build takes place
 Generate nuget packages on the build server
 Push packages to the nuget server

25. TFS 2013 new workflow
#vsalmdeep
 Simplified Workflow
 Easily customizable
 Extensible out-of-the-box with scripts (es PowerShell)

26. DEMO
Publish nuget packages with new TFS 2013
build workflow and powershell
#vsalmdeep

27. Questions?
?
#vsalmdeep