Skip to content

Incorporate Dash Deployment into ALM

Jump to bottom Edit New page
James Baker edited this page Dec 30, 2015 · 1 revision

DASH is often required to support a separate, non-trivial cloud-based application with its own mechanisms for build, test and deployment. In these cases, it is sometimes appropriate to incorporate DASH into this Application Lifecycle Management (ALM) processes.

Prerequisites

The following prerequisites are required in order to successfully build and deploy DASH (generally on a dedicated build server):

Cloning the Repository

DASH is maintained in a public GitHub repository. The clone URI for this repository is:

https://github.com/MicrosoftDX/Dash.git

The source code for DASH can be cloned either one-time and preserved in the build location or (preferably) cloned each time the application is built (Git allows cloning to a specific commit or tag).

Building the Cloud Service Package for DASH

DASH is an Azure Cloud Service. The Azure SDK provides tools to build the required artifacts (.cspkg & .cscfg) to deploy the cloud service. These build tools integrate with the msbuild tool.

DASH is available in 2 flavors, manifest via distinct cloud service projects:

  • HTTP endpoint only - /DashServer.Azure/DashServer.Azure.ccproj
  • HTTP and HTTPS endpoints - /DashServer.Azure.Https/DashServer.Azure.Https.ccproj

When building DASH the project associated with the desired configuration must be specified as the project to msbuild. The usage to build DASH is as follows:

msbuild {project} /t:Publish /p:Configuration=Release;PublishDir={outpath} [/p:TargetProfile={configuration}] [/p:SourceServiceConfiguration={config_file_name}]

where:
  project: the relative or fully-qualified file name of the desired project to build (DashServer.Azure.ccproj or DashServer.Azure.Https.ccproj)
  outpath: the directory name (including trailing backslash) where the output artifacts should be written to
  configuration: the name of the built-in configuration to be used as the cloud service configuration file (.cscfg). The built-in configuration files are; ServiceConfiguration.Cloud.cscfg or ServiceConfiguration.Publish.cscfg. The value to specify is 'Cloud' or 'Publish' respectively
  config_file_name: the relative or fully-qualified file name of the .cscfg file to be used as the cloud service configuration file. Note that the filename is relative to the .ccproj project file.

Specifying DASH Configuration

If repeatedly building and deploying DASH, it will be common to want to use the same configuration. The configuration can be maintained and specified in 3 different ways:

  1. Maintain the configuration in one of the .cscfg files included in the DASH source repository and specify using the TargetProfile property. While this approach is relatively straight forward, you will need to manage resolving any future conflicts when changes occur to these files in the DASH codebase. Additionally, this approach is not applicable if making a fresh clone of the DASH repository each time you build.
  2. Maintain a separate .cscfg file outside of the DASH directory structure and specify using the SourceServiceConfiguration property. Using this approach allows you to maintain the .cscfg file independently of the DASH codebase and you may be able to check-in the file to the application's own repository. Note that since this file will contain the account keys (the secrets) for the DASH account, it may not be a great idea to store this in a source control repository. Instead, consider a 'lock box' style design where only a trusted principal (ie. the build server) may retrieve the file.
  3. Download the existing .cscfg file from the already deployed DASH service and specify this temporary file using the SourceServiceConfiguration property.

Deploying the Built Artifacts

There are numerous approaches to deploying Azure Cloud Services from build environments, including Powershell and msbuild tasks. A key point to decide is whether or not you want to deploy directly to the 'Production' slot or the 'Staging' slot and VIP-swapping. Both approaches ensure that the DASH service is updated without any disruption to the service. Deploying directly to 'Production' requires less billable resources and is less complex, however there is no way to verify the operation of the newly-deployed service or roll-back if a fault is detected. Deploying to the 'Staging' slot enables the deployment logic to perform 'smoke' tests without disrupting the production service. Additionally, if a fault is detected in the new deployment (either during smoke testing or even after swapping to production) the prior version may be 'rolled-back' without interruption. This approach does require additional short-term billable resources (staging VMs) and the logic to manage multiple slots is more complex.

Add a custom footer
Add a custom sidebar
Clone this wiki locally