This document discusses various DevOps practices and tools for continuous delivery including deploying to Windows Azure. It describes principles of continuous delivery like deploying changes quickly and reliably. Delivery models from no process to collaborative are presented. Practices like automating everything, versioning configurations, and deploying the same way to every environment are recommended. Tools covered include Chef for infrastructure as code, Vagrant for reproducible environments, Juju for OpenStack, and Release Management for .NET teams. The document encourages thinking about additional delivery practices and patterns.

1. DevOps: Continuous Delivery and
Windows Azure
Ibon Landa
Plain Concepts

3. 



7. Our highest priority is to satisfy the customer through early
and continuous delivery of valuable software.
Principles behind the Agile Manifesto

8. How long would ittakeyour
organizationto deploya changethat
involvesjust one singleline ofcode?
Doyou dothis on arepeatable,reliable
basis?
Mary& Tom Poppendieck
Implementing Lean Software Development

9. Done means "released". This implies ownership of a project
right up until it’s in the hands of the user,and working
properly. There’s noneof this "I’ve checked in my code so it’s
done as far as I’m concerned".
James Betteley

10. SOFTWARE
DELIVERY
MODELS

11. #1: No model, or random delivery.

12. #2: Let the operations guys figure out.

13. #3: Defined and collaborative approach.

14. DELIVERY PRACTICES

15. Version
everything

16. Automate
everything

17. Tokenize
configurations

18. Use one-click deployments

19. Deploy to a copy of
production

20. Deploy the same way to every
environment

21. Have always a rollback
mechanism in place.

23. Lock down
the environments.

24. Build
only
once

25. Measure the delivery process

26. 26
Optimización de despliegues
1 2 3 Weeks
Provisioning new HW
SW
Install/
config
QA
Certif.
On-premises
Windows Azure
From 1-3 weeks to 30 minutes
Every machine certified separately
Basic checks prior to switch from staging
QA
Certif.

27. Bring the pain forward

28. Practice
DevOps!

29. Build a release pipeline

33. Virtual Networks
(10.0.0.0/16)
(10.2.0.0/16)
(10.1.0.0/16)
10.0.0.10
10.0.0.11
131.57.23.120
10.2.2.0/24 10.2.3.0/24
10.2.2.0/24 10.2.3.0/24
65.52.249.22 10.1.0.4 10.1.1.4

34. Continuous Delivery

37. Recipes and Cookbooks
thatUSEE:
Recipes and Cookbooks that describe and
deliver code.
Chef enables people to easily build &
manage complex & dynamic applications
at massive scale.
• New model for describing infrastructure that
promotes reuse
• Programmatically provision and configure
• Reconstruct business from code repository,
data backup, and bare metal resources
What is Chef?
Chef is an IT automation platform for developers & systems engineers to continuously
define, build, and manage infrastructure.
CHEF USES:

39. Organizations
Environments
Roles
Nodes
Recipes
Resources
Cookbooks
Run-lists
Chef Concepts

40. ■Azure plugin for Chef
■Request new VM from Azure API
■Bootstrap it over WinRM
■Install and start Chef
■Register with Chef server
■Run through the “run list”
■Instant infrastructure with one command
Provisioning with Chef

48. ■Easy to configure, reproducible, and portable work
environments
■VirtualBox, Hyper-V, VMware, AWS, or any other
provider. Windows Azure is not supported now.
■Shell scripts, Chef, or Puppet, can be used to
automatically install and configure software on the
machine
■Vagrant uses a base images: Boxes
■This Vagrant plugin allows you to standup Windows
guests using WinRM instead of SSH
Why vagrant?

54. ■Automate your OpenStack cloud infrastructure
■Juju Charms define applications as services
■An Ubuntu, OSX or Windows machine to install the client on
■GUI or command-line
Ubuntu juju

55. Charms for everything you need

58. juju generate-config

62. ALM your way

63. ■A continuous deployment solution for .NET teams
■Automates the deployment process
■Simplifies managing multiple environments
■Improves collaboration throughout the process
■Provides release analytics and reporting
■History
■Originally launched in 2009 as InRelease by InCycle Software
■InRelease 2.0 launched in 2010, 3.0 in 2013
■Acquired by Microsoft in 2013
Release Management

64. Automation

65. Collaboration

66. Team Foundation Server integration

67. Analytics & reporting

69. What about your own patterns & practices?
Think about some delivery practice not covered in the session.
Thanks @jlsoriat!
http://aka.ms/ReleasePipeline

71. Thanks!

72. Madrid
29 de Marzo

73. http://spain.windowsazurebootcamp.org