4. 4CONFIDENTIAL
Continuous Delivery is a software development discipline
where you build software in such a way that the software
can be released to production at any time.
You achieve continuous delivery by continuously integrating
the software done by the development team, building
executables, and running automated tests on those
executables to detect problems. Furthermore you push the
executables into increasingly production-like environments
to ensure the software will work in production.
CONTINUOUS DELIVERY (CD)
Definition by Martin Fowler
5. 5CONFIDENTIAL
RELEASE MANAGEMENT
Release management is the process of managing, planning,
scheduling and controlling a software build through
different stages and environments; including testing and
deploying software releases.
ITIL Release and Deployment Management aims to plan,
schedule and control the movement of releases to test and
live environments.
from wiki
8. 8CONFIDENTIAL
GIT FLOW BRANCHING MODEL
• Reflects development model
• DEVELOP branch reflects
new development stage
• RELEASE branch reflects
Release Hardening stage
• MASTER reflects the latest
stable version of the system
11. 11CONFIDENTIAL
• Build your binaries only once
• Separate environment-specific configuration
from the environment-agnostic binaries
• Deploy the same way to every environment
• Smoke test your deployments
CI/CD BEST PRACTICES
12. 12CONFIDENTIAL
GIT FLOW CD – DEVELOPMENT STAGE
Commit to Develop Branch
Build Unit Tests
Component
Tests
Publish
Artifacts BUILD
DEPLOY
Deploy to
DEV
Acceptance
Tests
Propagate to
QA
Manual
Testing
Approve
13. 13CONFIDENTIAL
GIT FLOW CD – RELEASE TAGE
Commit to Release Branch
Build Unit Tests
Component
Tests
Publish
Artifacts
Deploy to
STAGING
Acceptance
Tests
Manual
Testing
Approve
Propagate to
PRODUCTION
Smoke TestsDONE
15. 15CONFIDENTIAL
• Comprehensive set of build tasks in the cloud
• Built-in code coverage
• Extensions Marketplace
• Can Trigger build on commit or on schedule
• Email Alerts on build failure
• Integration with O365 Users
• Built-in artifact storage and package manager
TOOLS – BUILD – VS TEAM SERVICES
19. 20CONFIDENTIAL
• Does one thing, does it well: Automated deployment for
.NET
• Build by .NET Developers for .NET Developers
• Comprehensive functionality and documentation
• Integration with all popular CI servers: Jenkins, TeamCity,
Visual Studio Team Services
• Installs in minutes
• Affordable prices, free for small systems
WHY OCTOPUS DEPLOY
20. 21CONFIDENTIAL
• Environment management
• Life-cycle management
• Project deployment pipeline management
• Release Management
• Works with internal and external nugget package feed
• Approvals and manual intervention
• Integration with VSTS through Marketplace Build Tasks
OCTOPUS DEPLOY MAIN FEATURES
21. 22CONFIDENTIAL
• Variable management
• Application settings value replacement
• Swapping connection strings
• Configuring IIS application pools and web sites
• Installing and updating Windows Services
• Supports deployment to Azure Cloud Services and App
Services
• Extendable with own PowerShell scripts and custom steps
DEPLOY - CONFIGURATION AND SCRIPTING
26. 27CONFIDENTIAL
TIP – PARAMETERS MANAGEMENT
• Global infrastructure parameters
• Project-scoped parameters used in for configuration
settings
• Keep unambiguous parameter naming
• Calculate project parameters from global
GROUP PARAMETERS
27. 28CONFIDENTIAL
TIP – UNAMBIGUOUS PARAMETER NAMING
EXAMPLE
<add name="default" connectionString="#{api__defaultConnectionString}"
xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
#{apiUserSqlCreds};#{apiConnectionString};Application Name=API
31. 32CONFIDENTIAL
PACKAGE VERSIONING
INFORMATION NUGET PACKAGE PROPERTY
Development Cycle / Branch Name
Build Number Name, Version, Octopus Release Number
Git Commit Description
Build Queued By Description
Build Definition Name Description
PACKAGE METADATA
32. 33CONFIDENTIAL
• Plan the scope of release
• Deploy only components with modifications
• Check the status of deployment on Dashboard
TIP - DEPLOY FROM OCTOPUS DEPLOY
34. 35CONFIDENTIAL
• Resource Group – logically grouped collection of entities that usually
share a common lifecycle
• Resource Provider – Azure service which manages specific services
• Resource Manager Template - declarative JSON file that defines the
goal state of a deployment
• Parameters - values provided by the user executing the deployment to
customize deployed resources
• Deployment - operation which tracks execution of a Resource Manager
template
AZURE RESOURCE MANAGER (ARM) API
35. 38CONFIDENTIAL
[TOPIC]
xxxD
xxxOps
xxxQ xxxS xxxP
• Resource Group (RG) contains all resources which
belong to particular environment.
• RG name starts with common prefix and the letter,
which identifies the environment purpose: Dev, Qa,
Staging and Production
• RG name is included into the billing report and used to
track costs.
RESOURCE GROUPS AS CONTAINERS
36. 39CONFIDENTIAL
network-01 (v2)
[TOPIC]
RESOURCE GROUP
front-subnet-01
back-subnet-01
Gateway Subnet
network-01 (Classic)
Gateway Subnet
Use Network Security Groups to limit
ports exposure on the subnet layer.
FE subnet network security Group:
Inbound Connections:
- Allow all HTTP and HTTPS from any
source
- Allow all from AD network address
space
- Allow/Block RDP connections from
EPAM and NYC offices
- Allow Octopus port from Virtual
Network
BE subnet network security Group:
Inbound Connections:
- Allow application ports from VNet
- Allow all from AD network address
space
- Allow/Block RDP connections from
EPAM and NYC offices
- Allow Octopus port from Virtual
Network
NETWORK SECURITY GROUPS
38. 41CONFIDENTIAL
Element Required Description
$schema Yes Location of the JSON schema file.
contentVersion Yes Version of the template.
parameters No Values provided during deployment execution.
variables No Internal variables
resources Yes Azure services deployed or updated in a
resource group
outputs No Values that are returned after deployment
EASY PROVISIONING - RESOURCE TEMPLATE
40. 45CONFIDENTIAL
RBAC BUILT-IN ROLES
Role name Permissions
Owner Full management rights
Contributor Full management rights except for user management
Reader View resources and their settings
None Does not see resources
CORE ROLES
Role name Permissions
*** Contributor Full management rights except for user management on
specific types of resources.
Examples: Virtual Machine Contributor, SQL DB
Contributor
RESOURCE TYPE SPECIFIC ROLES
41. 46CONFIDENTIAL
• Branching model should fit your development process
• Use VSTS for CI process and Automated Tests Run
• Use Octopus Deploy for Release Management
• VSTS + Octopus Deploy integrates perfectly together
• Use ARM for environments provisioning
• Leverage RBAC for control permissions on service
administration
WRAP UP
During each iteration (sprint) development team works in two stages:
1. New feature development or bug fixing. All changes commits to the integration branch, which might be temporary unstable.
2. Preparing the release candidate and testing it, to produce the stable release code at the end of the iteration and initiate the push the new version to production environments
At the beginning of each iteration all team works on new feature to produce the value.
At the end of the sprint most of the team focused on the stabilizing and hardening the quality of iteration deliverables while some of the team members might keep working on the scope of the next iteration.
In addition to minimal model the release stage includes own DEV and QA environments, called DEV2 and QA2 respectably
DEV2 is used to test automated deployment scripts and to run automated acceptance tests.
QA2 is used for exploratory testing and running manual regression tests over the Release Candidate.
It’s good practice to have STAGE as a mirror of PROD. This allows to implement the Zero Downtime deployment strategies, like Canary Releases and Blue-Green Deployment.
Hotfix is follows the release candidate flow.
Release stage starts with creating release branch from the develop.
The minimal pipeline includes only Staging and Production environments, where Staging is used for simulation of upgrading production version and also to run Automated and Manual Acceptance Tests. Staging can also be used as UAT environment for stakeholders.
Release stage uses own CI builds which produces binaries. Binaries from Release CI build are propagated to the Production.
VSTS provides comprehensive build tool with large number of tasks for all popular build tools and also can be extended from the VSTS Marketplace.
Supports git capabilities to trigger build on changes in the
No two environments are ever the same. Use variables to scope different settings to different environments. Built-in conventions mean that Octopus automatically takes care of:
VSTS Task push application binaries as nugget package to the Octopus. It defines the name and the version of the package and also creates a new release for the project
Octopus Deploy Server call Octopus Tentacles, agent application. installed on the VM. Tentacle receives the package and do the deployment and deploy-time config transformations.
For PaaS services, like WebApps and Cloud Service Roles, all transformation is performed on the Octopus Server.
Artefacts, get files after deployment
Use
https://azure.microsoft.com/en-gb/documentation/articles/role-based-access-control-configure/#known-issues-when-using-role-based-access-control
Azure Resource Manager enables you to work with the resources in your application as a group. You can deploy, update or delete all of the resources for your application in a single, coordinated operation. You use a template for deployment and that template can work for different environments such as testing, staging and production. You can clarify billing for your organization by viewing the rolled-up costs for the entire group.
https://azure.microsoft.com/en-gb/documentation/articles/role-based-access-control-configure/#known-issues-when-using-role-based-access-control
Azure Resource Manager enables you to work with the resources in your application as a group. You can deploy, update or delete all of the resources for your application in a single, coordinated operation. You use a template for deployment and that template can work for different environments such as testing, staging and production. You can clarify billing for your organization by viewing the rolled-up costs for the entire group.
https://azure.microsoft.com/en-gb/documentation/articles/role-based-access-control-configure/#known-issues-when-using-role-based-access-control
Azure Resource Manager enables you to work with the resources in your application as a group. You can deploy, update or delete all of the resources for your application in a single, coordinated operation. You use a template for deployment and that template can work for different environments such as testing, staging and production. You can clarify billing for your organization by viewing the rolled-up costs for the entire group.
Back-subnet-01 VNet subnet contains SOLR and other application services which are not exposed to the Internet.
Front-subnet-01 VNet subnet contains web servers.
Classic VNet is used only to host Cloud Service – Worker Role, which must be in VNet to access internal load balancer endpoint on SOLR instances.
Access to another VNet with AD and domain servers is organized through the VNet-2-VNet gateway connection.
Build and deploy servers can access to VMs through the VNet-2-VNet gateway connection. Network Security Group controls that Octopus Deploy port is accessed only from Azure VNet.
Infrastructure, Data and Application resources has different lifecycle, so it’s better to script them separately.
Manually Configured Resources:
Classic VLAN to VLAN v2 Site-2-Site VPN
Run Copy Database from Production to Staging