PageRenderTime 29ms CodeModel.GetById 14ms RepoModel.GetById 0ms app.codeStats 0ms

/articles/app-service-web/app-service-web-staged-publishing-realworld-scenarios.md

https://gitlab.com/yeah568/azure-content
Markdown | 448 lines | 314 code | 134 blank | 0 comment | 0 complexity | be328a412ea6e70b7aa4f271c98c32ca MD5 | raw file
    

  1. <properties
    2. 

  2.    pageTitle="Use DevOps environments effectively for your web app"
    3. 

  3.    description="Learn how to use deployment slots to setup and manage multiple development environments for your application"
    4. 

  4.    services="app-service\web"
    5. 

  5.    documentationCenter=""
    6. 

  6.    authors="sunbuild"
    7. 

  7.    manager="yochayk"
    8. 

  8.    editor=""/>
    9. 

  9. 

  10. <tags
    11. 

  11.    ms.service="app-service"
    12. 

  12.    ms.devlang="na"
    13. 

  13.    ms.topic="article"
    14. 

  14.    ms.tgt_pltfrm="na"
    15. 

  15.    ms.workload="web"
    16. 

  16.    ms.date="05/31/2016"
    17. 

  17.    ms.author="sumuth"/>
    18. 

  18. 

  19. # Use DevOps environments effectively for your web apps
    20. 

  20. 

  21. This article shows you how to setup and manage web application deployments  for multiple versions of your application such as development, staging, QA and production. Each version of your application can be considered a development environment for a specific need within your deployment process, for example QA environment can be used by your team of developers to test the quality of the application before you push the changes to production.
    22. 

  22. Setting up multiple development environments can be a challenging task as you need to track and manage the resources (compute, web app, database, cache etc.) across these environments and deploy content from one environment to another.
    23. 

  23. 

  24. ## Setting up a non-production environment (stage,dev,QA)
    25. 

  25. Once you have a production web app up and running, the next step is to create a non-production environment. In order to use deployment slots make sure you are running in the **Standard** or **Premium** App Service plan mode. Deployment slots are actually live web apps with their own hostnames. Web app content and configuration elements can be swapped between two deployment slots, including the production slot. Deploying your application to a deployment slot has the following benefits:
    26. 

  26. 

  27. 1. You can validate web app changes in a staging deployment slot before swapping it with the production slot.
    28. 

  28. 2. Deploying a web app to a slot first and swapping it into production ensures that all instances of the slot are warmed up before being swapped into production. This eliminates downtime when you deploy your web app. The traffic redirection is seamless, and no requests are dropped due to swap operations. This entire workflow can be automated by configuring [Auto Swap](web-sites-staged-publishing.md#configure-auto-swap-for-your-web-app) when pre-swap validation is not needed.
    29. 

  29. 3. After a swap, the slot with previously staged web app now has the previous production web app. If the changes swapped into the production slot are not as you expected, you can perform the same swap immediately to get your "last known good web app" back.
    30. 

  30. 

  31. To setup a staging deployment slot, see [Set up staging environments for web apps in Azure App Service](web-sites-staged-publishing.md) . Every environment should include its own set of resources, for example if your web app uses a database then both production web app and staging web app should be using different databases.  Add staging development environment resources such as database, storage or cache for setting up your staging development environment.
    32. 

  32. 

  33. ## Examples of using multiple development environments
    34. 

  34. 

  35. Any project should follow a source code management with at least two environments, a development and production environment, but when using Content management systems, Application frameworks etc we might run into issues where the application does not support this scenario out of the box. This is true for some of the popular frameworks discussed below. Lots of questions come to mind when working with a CMS/frameworks such as
    36. 

  36. 

  37. 1. How to break it out into different environments
    38. 

  38. 2. What files can I change and wont impact framework version updates
    39. 

  39. 3. How to manage configuration per environment
    40. 

  40. 4. How to manage modules/plugins version updates,core framework version updates
    41. 

  41. 

  42. There are many ways to setup a multiple environment for your project and the examples below are just one such method for the respective applications.
    43. 

  43. 

  44. ### WordPress
    45. 

  45. In this section you will learn how to setup a deployment workflow using slots for WordPress. WordPress like most CMS solutions does not support working with multiple development environments out of the box. App Service Web Apps have a few features that make it easier to store configuration settings outside of your code.
    46. 

  46. 

  47. Before creating a staging slot, setup your application code to support multiple environments. To support multiple environments in WordPress you need to edit `wp-config.php` on your local development web app add the following code at the beginning of the file. This will allow your application to pick the correct configuration based on the selected environment.
    48. 

  48. 

  49. 

  50. 	// Support multiple environments
    51. 

  51. 	// set the config file based on current environment
    52. 

  52. 	/**/
    53. 

  53. 	if (strpos(filter_input(INPUT_SERVER, 'HTTP_HOST', FILTER_SANITIZE_STRING),'localhost') !== false) {
    54. 

  54. 	    // local development
    55. 

  55. 	    $config_file = 'config/wp-config.local.php';
    56. 

  56. 	}
    57. 

  57. 	elseif  ((strpos(getenv('WP_ENV'),'stage') !== false) ||  (strpos(getenv('WP_ENV'),'prod' )!== false )){
    58. 

  58. 	      //single file for all azure development environments
    59. 

  59. 	      $config_file = 'config/wp-config.azure.php';
    60. 

  60. 	}
    61. 

  61. 	$path = dirname(__FILE__) . '/';
    62. 

  62. 	if (file_exists($path . $config_file)) {
    63. 

  63. 	    // include the config file if it exists, otherwise WP is going to fail
    64. 

  64. 	    require_once $path . $config_file;
    65. 

  65. 	}
    66. 

  66. 

  67. 

  68. 

  69. Create a folder under web app root called `config` and add two files: `wp-config.azure.php`  and `wp-config.local.php`  representing your azure and local environment respectively.
    70. 

  70. 

  71. Copy the following in `wp-config.local.php` :
    72. 

  72. 

  73. ```
    74. 

  74. 	
    75. 

  75. 	<?php
    76. 

  76. 	
    77. 

  77. 	// MySQL settings
    78. 

  78. 	/** The name of the database for WordPress */
    79. 

  79. 	
    80. 

  80. 	define('DB_NAME', 'yourdatabasename');
    81. 

  81. 	
    82. 

  82. 	/** MySQL database username */
    83. 

  83. 	define('DB_USER', 'yourdbuser');
    84. 

  84. 	
    85. 

  85. 	/** MySQL database password */
    86. 

  86. 	define('DB_PASSWORD', 'yourpassword');
    87. 

  87. 	
    88. 

  88. 	/** MySQL hostname */
    89. 

  89. 	define('DB_HOST', 'localhost');
    90. 

  90. 	/**
    91. 

  91. 	 * For developers: WordPress debugging mode.
    92. 

  92. 	 * * Change this to true to enable the display of notices during development.
    93. 

  93. 	 * It is strongly recommended that plugin and theme developers use WP_DEBUG
    94. 

  94. 	 * in their development environments.
    95. 

  95. 	 */
    96. 

  96. 	define('WP_DEBUG', true);
    97. 

  97. 	
    98. 

  98. 	//Security key settings
    99. 

  99. 	define('AUTH_KEY',         'put your unique phrase here');
    100. 

  100. 	define('SECURE_AUTH_KEY',  'put your unique phrase here');
    101. 

  101. 	define('LOGGED_IN_KEY',    'put your unique phrase here');
    102. 

  102. 	define('NONCE_KEY',        'put your unique phrase here');
    103. 

  103. 	define('AUTH_SALT',        'put your unique phrase here');
    104. 

  104. 	define('SECURE_AUTH_SALT', 'put your unique phrase here');
    105. 

  105. 	define('LOGGED_IN_SALT',   'put your unique phrase here');
    106. 

  106. 	define('NONCE_SALT',       'put your unique phrase here');
    107. 

  107. 	
    108. 

  108. 	/**
    109. 

  109. 	 * WordPress Database Table prefix.
    110. 

  110. 	 *
    111. 

  111. 	 * You can have multiple installations in one database if you give each a unique
    112. 

  112. 	 * prefix. Only numbers, letters, and underscores please!
    113. 

  113. 	 */
    114. 

  114. 	$table_prefix  = 'wp_';
    115. 

  115. ```
    116. 

  116. 

  117. Setting the security keys above can help preventing your web app from being hacked, so use unique values. If you need to generate the string for security keys mentioned above, you can go to the automatic generator to create new keys/values using this [link] (https://api.wordpress.org/secret-key/1.1/salt)
    118. 

  118. 

  119. Copy the following code in `wp-config.azure.php`:
    120. 

  120. 

  121. 

  122. ```
    123. 

    124. 

  124. 	<?php
    125. 

  125. 	// MySQL settings
    126. 

  126. 	/** The name of the database for WordPress */
    127. 

  127. 	
    128. 

  128. 	define('DB_NAME', getenv('DB_NAME'));
    129. 

  129. 	
    130. 

  130. 	/** MySQL database username */
    131. 

  131. 	define('DB_USER', getenv('DB_USER'));
    132. 

  132. 	
    133. 

  133. 	/** MySQL database password */
    134. 

  134. 	define('DB_PASSWORD', getenv('DB_PASSWORD'));
    135. 

  135. 	
    136. 

  136. 	/** MySQL hostname */
    137. 

  137. 	define('DB_HOST', getenv('DB_HOST'));
    138. 

  138. 	
    139. 

  139. 	/**
    140. 

  140. 	* For developers: WordPress debugging mode.
    141. 

  141. 	*
    142. 

  142. 	* Change this to true to enable the display of notices during development.
    143. 

  143. 	* It is strongly recommended that plugin and theme developers use WP_DEBUG
    144. 

  144. 	* in their development environments.
    145. 

  145. 	* Turn on debug logging to investigate issues without displaying to end user. For WP_DEBUG_LOG to
    146. 

  146. 	* do anything, WP_DEBUG must be enabled (true). WP_DEBUG_DISPLAY should be used in conjunction
    147. 

  147. 	* with WP_DEBUG_LOG so that errors are not displayed on the page */
    148. 

  148. 	
    149. 

  149. 	*/
    150. 

  150. 	define('WP_DEBUG', getenv('WP_DEBUG'));
    151. 

  151. 	define('WP_DEBUG_LOG', getenv('TURN_ON_DEBUG_LOG'));
    152. 

  152. 	define('WP_DEBUG_DISPLAY',false);
    153. 

  153. 	
    154. 

  154. 	//Security key settings
    155. 

  155. 	/** If you need to generate the string for security keys mentioned above, you can go the automatic generator to create new keys/values: https://api.wordpress.org/secret-key/1.1/salt **/
    156. 

  156. 	define('AUTH_KEY' ,getenv('DB_AUTH_KEY'));
    157. 

  157. 	define('SECURE_AUTH_KEY',  getenv('DB_SECURE_AUTH_KEY'));
    158. 

  158. 	define('LOGGED_IN_KEY', getenv('DB_LOGGED_IN_KEY'));
    159. 

  159. 	define('NONCE_KEY', getenv('DB_NONCE_KEY'));
    160. 

  160. 	define('AUTH_SALT',  getenv('DB_AUTH_SALT'));
    161. 

  161. 	define('SECURE_AUTH_SALT', getenv('DB_SECURE_AUTH_SALT'));
    162. 

  162. 	define('LOGGED_IN_SALT',   getenv('DB_LOGGED_IN_SALT'));
    163. 

  163. 	define('NONCE_SALT',   getenv('DB_NONCE_SALT'));
    164. 

  164. 	
    165. 

  165. 	/**
    166. 

  166. 	* WordPress Database Table prefix.
    167. 

  167. 	*
    168. 

  168. 	* You can have multiple installations in one database if you give each a unique
    169. 

  169. 	* prefix. Only numbers, letters, and underscores please!
    170. 

  170. 	*/
    171. 

  171. 	$table_prefix  = getenv('DB_PREFIX');
    172. 

  172. ```
    173. 

  173. 

  174. #### Use Relative Paths
    175. 

  175. One last thing is to allow the WordPress app to use relative paths. WordPress stores URL information in the database. This makes moving content from one environment to another more difficult as you need to update the database every time you move from local to stage or stage to production environments. To reduce the risk of issues that can be caused with deploying a database every time you deploy from one environment to another use the [Relative Root links  plugin](https://wordpress.org/plugins/root-relative-urls/) which can be installed using WordPress administrator dashboard or download it manually from [here](https://downloads.wordpress.org/plugin/root-relative-urls.zip).
    176. 

  176. 

  177. Add the following entries to your `wp-config.php` file before the `That's all, stop editing!` comment:
    178. 

  178. 

  179. ```
    180. 

    181. 

  181.     define('WP_HOME', 'http://' . filter_input(INPUT_SERVER, 'HTTP_HOST', FILTER_SANITIZE_STRING));
    182. 

  182. 	define('WP_SITEURL', 'http://' . filter_input(INPUT_SERVER, 'HTTP_HOST', FILTER_SANITIZE_STRING));
    183. 

  183. 	define('WP_CONTENT_URL', '/wp-content');
    184. 

  184. 	define('DOMAIN_CURRENT_SITE', filter_input(INPUT_SERVER, 'HTTP_HOST', FILTER_SANITIZE_STRING));
    185. 

  185. ```
    186. 

  186. 

  187. Activate the plugin through the `Plugins` menu in WordPress Administrator dashboard.  Save your permalink settings for WordPress app.
    188. 

  188. 

  189. #### The final `wp-config.php` file
    190. 

  190. Any WordPress Core updates will not affect your `wp-config.php` , `wp-config.azure.php` and `wp-config.local.php` files  . In the end the `wp-config.php` file will look like this
    191. 

  191. 

  192. ```
    193. 

    194. 

  194. 	<?php
    195. 

  195. 	/**
    196. 

  196. 	 * The base configurations of the WordPress.
    197. 

  197. 	 *
    198. 

  198. 	 * This file has the following configurations: MySQL settings, Table Prefix,
    199. 

  199. 	 * Secret Keys, and ABSPATH. You can find more information by visiting
    200. 

  200. 	 *
    201. 

  201. 	 * Codex page. You can get the MySQL settings from your web host.
    202. 

  202. 	 *
    203. 

  203. 	 * This file is used by the wp-config.php creation script during the
    204. 

  204. 	 * installation. You don't have to use the web web app, you can just copy this file
    205. 

  205. 	 * to "wp-config.php" and fill in the values.
    206. 

  206. 	 *
    207. 

  207. 	 * @package WordPress
    208. 

  208. 	 */
    209. 

  209. 	
    210. 

  210. 	// Support multiple environments
    211. 

  211. 	// set the config file based on current environment
    212. 

  212. 	if (strpos($_SERVER['HTTP_HOST'],'localhost') !== false) { // local development
    213. 

  213. 	    $config_file = 'config/wp-config.local.php';
    214. 

  214. 	}
    215. 

  215. 	elseif  ((strpos(getenv('WP_ENV'),'stage') !== false) ||  (strpos(getenv('WP_ENV'),'prod' )!== false )){
    216. 

  216. 	    $config_file = 'config/wp-config.azure.php';
    217. 

  217. 	}
    218. 

  218. 	
    219. 

  219. 	
    220. 

  220. 	$path = dirname(__FILE__) . '/';
    221. 

  221. 	if (file_exists($path . $config_file)) {
    222. 

  222. 	    // include the config file if it exists, otherwise WP is going to fail
    223. 

  223. 	    require_once $path . $config_file;
    224. 

  224. 	}
    225. 

  225. 	
    226. 

  226. 	/** Database Charset to use in creating database tables. */
    227. 

  227. 	define('DB_CHARSET', 'utf8');
    228. 

  228. 	
    229. 

  229. 	/** The Database Collate type. Don't change this if in doubt. */
    230. 

  230. 	define('DB_COLLATE', '');
    231. 

  231. 	
    232. 

  232. 	
    233. 

  233. 	/* That's all, stop editing! Happy blogging. */
    234. 

  234. 	
    235. 

  235. 	define('WP_HOME', 'http://' . filter_input(INPUT_SERVER, 'HTTP_HOST', FILTER_SANITIZE_STRING));
    236. 

  236. 	define('WP_SITEURL', 'http://' . filter_input(INPUT_SERVER, 'HTTP_HOST', FILTER_SANITIZE_STRING));
    237. 

  237. 	define('WP_CONTENT_URL', '/wp-content');
    238. 

  238. 	define('DOMAIN_CURRENT_SITE', filter_input(INPUT_SERVER, 'HTTP_HOST', FILTER_SANITIZE_STRING));
    239. 

  239. 	
    240. 

  240. 	/** Absolute path to the WordPress directory. */
    241. 

  241. 	if ( !defined('ABSPATH') )
    242. 

  242. 		define('ABSPATH', dirname(__FILE__) . '/');
    243. 

  243. 	
    244. 

  244. 	/** Sets up WordPress vars and included files. */
    245. 

  245. 	require_once(ABSPATH . 'wp-settings.php');
    246. 

  246. ```
    247. 

  247. 

  248. #### Setup a Staging Environment
    249. 

  249. Assuming you already have a WordPress web app running on Azure Web, login to [Azure Portal](https://portal.azure.com/) and go to your WordPress web app. If not you can create one from the marketplace. To learn more, click [here](web-sites-php-web-site-gallery.md).
    250. 

  250. Click on **Settings** -> **Deployment slots** -> **Add** to create a deployment slot with the name stage. A deployment slot is another web application sharing the same resources as the primary web app created above.
    251. 

  251. 

  252. ![Create stage deployment slot](./media/app-service-web-staged-publishing-realworld-scenarios/1setupstage.png)
    253. 

  253. 

  254. Add another MySQL database, say `wordpress-stage-db` to your resource group `wordpressapp-group`.
    255. 

  255. 

  256.  ![Add MySQL database to resourec group](./media/app-service-web-staged-publishing-realworld-scenarios/2addmysql.png)
    257. 

  257. 

  258. Update the Connection strings for your stage deployment slot to point to newly created database, `wordpress-stage-db`. Note that your production web app , `wordpressprodapp` and staging web app `wordpressprodapp-stage` must point to different databases.
    259. 

  259. 

  260. #### Configure environment-specific app settings
    261. 

  261. Developers can store key-value string pairs in Azure as part of the configuration information associated with a web app called App Settings. At runtime, App Service Web Apps automatically retrieve these values for you and make them available to code running in your web app.  From a security perspective that is a benefit since sensitive information such as database connection strings with passwords should never show up as clear text in a file such as `wp-config.php`.
    262. 

  262. 

  263. This process  defined below is useful when you perform updates as it includes both file changes and database changes for WordPress app:
    264. 

  264. 

  265. - WordPress version upgrade
    266. 

  266. - Add new or edit or upgrade Plugins
    267. 

  267. - Add new or edit or upgrade themes
    268. 

  268. 

  269. Configure app settings for:
    270. 

  270. 

  271. - database information
    272. 

  272. - turning on/off  WordPress logging
    273. 

  273. - WordPress security settings
    274. 

  274. 

  275. ![App Setings for Wordpress web app](./media/app-service-web-staged-publishing-realworld-scenarios/3configure.png)
    276. 

  276. 

  277. Make sure you have added the following app settings for your production web app and stage slot. Note that the production web app and Staging web app use different databases.
    278. 

  278. Uncheck **Slot Setting** checkbox for all the settings parameters except WP_ENV. This will swap the configuration for your web app, along with file content and database. If **Slot Setting** is **Checked**, the web app’s app settings and connection string configuration will NOT move across environments when doing a SWAP operation and hence if any database changes are present this will not break your production web app.
    279. 

  279. 

  280. Deploy the local development environment web app to stage web app and database using WebMatrix or tool(s) of your choice such as FTP , Git or PhpMyAdmin.
    281. 

  281. 

  282. ![Web Matrix Publish dialog for WordPress web app](./media/app-service-web-staged-publishing-realworld-scenarios/4wmpublish.png)
    283. 

  283. 

  284. Browse and test your staging web app. Considering a scenario where the theme of the web app is to be updated, here is the staging web app.
    285. 

  285. 

  286. ![Browse staging web app before swapping slots](./media/app-service-web-staged-publishing-realworld-scenarios/5wpstage.png)
    287. 

  287. 

  288. 

  289.  If all looks good, click on the **Swap** button on your staging web app to move your content to the production environment. In this case you swap the web app and the database across environments during every **Swap** operation.
    290. 

  290. 

  291. ![Swap preview changes for wordpress](./media/app-service-web-staged-publishing-realworld-scenarios/6swaps1.png)
    292. 

  292. 

  293.  > [AZURE.NOTE]
    294. 

  294.  >If you have a scenario where you need to only push files (no database updates), then **Check** the **Slot Setting** for all the database  related *app settings* and *connection strings settings* in web app setting blade within the Azure Portal before doing the SWAP. In this case DB_NAME, DB_HOST, DB_PASSWORD, DB_USER, default connection string setting should not show up in preview changes when doing a **Swap**. At this time, when you complete the **Swap** operation the WordPress web app will have the updated files **ONLY**.
    295. 

  295. 

  296. Before doing a SWAP, here is the production WordPress web app
    297. 

  297. ![Production web app before swapping slots](./media/app-service-web-staged-publishing-realworld-scenarios/7bfswap.png)
    298. 

  298. 

  299. After the SWAP operation, the theme has been updated on your production web app.
    300. 

  300. 

  301. ![Production web app after swapping slots](./media/app-service-web-staged-publishing-realworld-scenarios/8afswap.png)
    302. 

  302. 

  303. In a situation when you need to **rollback**, you can go to the production web app settings and click on the **Swap** button to swap the web app and database from production to staging slot. An important thing to remember is that if database changes are included with a **Swap** operation at any given time, then the next time you re-deploy to your staging web app you need to deploy the database changes to the current database for your staging web app which could be the previous production database or the stage database.
    304. 

  304. 

  305. #### Summary
    306. 

  306. To generalize the process for any application with a database
    307. 

  307. 

  308. 1. Install application on your local environment
    309. 

  309. 2. Include environment specific configuration (local and Azure Web App )
    310. 

  310. 3. Setup  your environments in App Service Web Apps– Staging , Production
    311. 

  311. 4. If you have a production application already running on Azure, sync your production content (files/code + database) to local and staging environment.
    312. 

  312. 5. Develop your application on your local environment
    313. 

  313. 6. Place your production web app under maintenance or locked mode and sync database content from production to staging and dev environments
    314. 

  314. 7. Deploy to Staging environment and Test
    315. 

  315. 8. Deploy to Production environment
    316. 

  316. 9. Repeat steps 4 through 6
    317. 

  317. 

  318. ### Umbraco
    319. 

  319. In this section you will learn how the Umbraco CMS uses a custom module to deploy from across multiple DevOps environment. This example provides you with a different approach to managing multiple development environments.
    320. 

  320. 

  321. [Umbraco CMS](http://umbraco.com/) is one of the popular .NET CMS solutions used by many developers which provides [Courier2](http://umbraco.com/products/more-add-ons/courier-2) module to deploy from development to staging to production environments. You can easily create a local development environment for an Umbraco CMS web app using Visual Studio or WebMatrix.
    322. 

  322. 

  323. 1. Create an Umbraco web app with Visual Studio, click [here](https://our.umbraco.org/documentation/Installation/install-umbraco-with-nuget) .
    324. 

  324. 2. To create an Umbraco web app with WebMatrix, click [here](http://umbraco.com/help-and-support/video-tutorials/getting-started/working-with-webmatrix).
    325. 

  325. 

  326. Always remember to remove the `install` folder under your application and never upload it to stage or production web apps. For this tutorial, I will be using WebMatrix
    327. 

  327. 

  328. #### Setup a staging environment
    329. 

  329. Create a deployment slot as mentioned above for Umbraco CMS web app, assuming you already have an Umbraco CMS web app up and running. If not you can create one from the marketplace.
    330. 

  330. 

  331. Update the Connection string for your stage deployment slot to point to newly created database, **umbraco-stage-db**. Your production web app (umbraositecms-1) and staging web app (umbracositecms-1-stage) **MUST** point to different databases.
    332. 

  332. 

  333. ![Update Connection string for staging web app with new staging database](./media/app-service-web-staged-publishing-realworld-scenarios/9umbconnstr.png)
    334. 

  334. 

  335. Click on **Get Publish settings** for the deployment slot **stage**. This will download a publish settings file that store all the information required by Visual Studio or Web Matrix to publish your application from local development web app to Azure web app.
    336. 

  336. 

  337.  ![Get publish setting of the staging web app](./media/app-service-web-staged-publishing-realworld-scenarios/10getpsetting.png)
    338. 

  338. 

  339. - Open your local development web app in **WebMatrix** or **Visual Studio**. In this tutorial I am using Web Matrix and first you need to import the publish settings file for your staging web app
    340. 

  340. 

  341. ![Import Publish settings for Umbraco using Web Matrix](./media/app-service-web-staged-publishing-realworld-scenarios/11import.png)
    342. 

  342. 

  343. - Review changes in the dialog box and deploy your local web app to your Azure web app, *umbracositecms-1-stage*. When you deploy files directly to your staging web app you will omit any files in the `~/app_data/TEMP/` folder as these will be regenerated when the stage web app is first started. You should also omit the `~/app_data/umbraco.config` file as this, too, will be regenerated.
    344. 

  344. 

  345. ![Review Publish changes in web matrix](./media/app-service-web-staged-publishing-realworld-scenarios/12umbpublish.png)
    346. 

  346. 

  347. - After successfully publishing the Umbraco local web app to staging web app, browse to your staging web app and run a few tests to rule out any issues.
    348. 

  348. 

  349. #### Setup Courier2 deployment module
    350. 

  350. With [Courier2](http://umbraco.com/products/more-add-ons/courier-2) module you can push content, stylesheets, development modules and more with a simple right-click from a staging web app to production web app for a more hassle free deployments and reducing risk of breaking your production web app when deploying an update.
    351. 

  351. Purchase a license for Courier2 for the domain `*.azurewebsites.net` and your custom domain (say http://abc.com) Once you have purchased the license, place the downloaded license (.LIC file) in the `bin` folder.
    352. 

  352. 

  353. ![Drop license file under bin folder](./media/app-service-web-staged-publishing-realworld-scenarios/13droplic.png)
    354. 

  354. 

  355. Download the Courier2 package from [here](https://our.umbraco.org/projects/umbraco-pro/umbraco-courier-2/) . Log on to your stage web app, say  http://umbracocms-site-stage.azurewebsites.net/umbraco and click on **Developer** Menu and Select **Packages** . Click on **Install** local package
    356. 

  356. 

  357. ![Umbraco Package installer](./media/app-service-web-staged-publishing-realworld-scenarios/14umbpkg.png)
    358. 

  358. 

  359. Upload the courier2 package using the installer.
    360. 

  360. 

  361. ![Upload package for courier module](./media/app-service-web-staged-publishing-realworld-scenarios/15umbloadpkg.png)
    362. 

  362. 

  363. To configure you need to update courier.config file under **Config** folder of your web app.
    364. 

  364. 

  365. ```xml
    366. 

  366. <!-- Repository connection settings -->
    367. 

  367.   <!-- For each site, a custom repository must be configured, so Courier knows how to connect and authenticate-->
    368. 

  368.   <repositories>
    369. 

  369.         <!-- If a custom Umbraco Membership provider is used, specify login & password + set the passwordEncoding to clear:  -->
    370. 

  370.         <repository name="production web app" alias="stage" type="CourierWebserviceRepositoryProvider" visible="true">
    371. 

  371.             <url>http://umbracositecms-1.azurewebsites.net</url>
    372. 

  372.             <user>0</user>
    373. 

  373.             <!--<login>user@email.com</login> -->
    374. 

  374.             <!-- <password>user_password</password>-->
    375. 

  375.            <!-- <passwordEncoding>Clear</passwordEncoding>-->
    376. 

  376.            </repository>
    377. 

  377.   </repositories>
    378. 

  378.  ```
    379. 

  379. 

  380. Under `<repositories>`, enter the production site URL and user information. If you are using default Umbraco Membership provider, then add the ID for the Administration user in <user> section . If you are using a custom Umbraco membership provider, use `<login>`,`<password>` to Courier2 module know how to connect to the production site. For more details, review the [documentation](http://umbraco.com/help-and-support/customer-area/courier-2-support-and-download/developer-documentation) for Courier module.
    381. 

  381. 

  382. Similarly, install Courier module on your production site and configure it point to stage web app in its respective courier.config file as shown here
    383. 

  383. 

  384. ```xml
    385. 

  385.   <!-- Repository connection settings -->
    386. 

  386.   <!-- For each site, a custom repository must be configured, so Courier knows how to connect and authenticate-->
    387. 

  387.   <repositories>
    388. 

  388.         <!-- If a custom Umbraco Membership provider is used, specify login & password + set the passwordEncoding to clear:  -->
    389. 

  389.         <repository name="Stage web app" alias="stage" type="CourierWebserviceRepositoryProvider" visible="true">
    390. 

  390.             <url>http://umbracositecms-1-stage.azurewebsites.net</url>
    391. 

  391.             <user>0</user>
    392. 

  392.            </repository>
    393. 

  393.   </repositories>
    394. 

  394. ```
    395. 

  395. 

  396. Click on Courier2 tab in Umbraco CMS web app  dashboard and select locations. You should see the repository name as mentioned in `courier.config`. Do this on both your production and staging web apps.
    397. 

  397. 

  398. ![View destination web app repository](./media/app-service-web-staged-publishing-realworld-scenarios/16courierloc.png)
    399. 

  399. 

  400. Now lets deploy some content from staging site to production site. Go to Content and select an existing page or create a new page. I will select an existing page from my web app where the title of the page is changed to **Getting Started – new** and now click on **Save and Publish**.
    401. 

  401. 

  402. ![Change Title of page and publish](./media/app-service-web-staged-publishing-realworld-scenarios/17changepg.png)
    403. 

  403. 

  404. Now select the modified page and *right click* to view all the options. Click on **Courier** to view Deployment dialog . Click on **Deploy** to initiate deployment
    405. 

  405. 

  406. ![Courier module deployment dialog](./media/app-service-web-staged-publishing-realworld-scenarios/18dialog1.png)
    407. 

  407. 

  408. Review the changes and click on Continue.
    409. 

  409. 

  410. ![Courier module deployment dialog review changes](./media/app-service-web-staged-publishing-realworld-scenarios/19dialog2.png)
    411. 

  411. 

  412. Deployment log shows if the deployment was successful.
    413. 

  413. 

  414.  ![View Deployment logs from Courier module](./media/app-service-web-staged-publishing-realworld-scenarios/20successdlg.png)
    415. 

  415. 

  416. Browse your production web app to see if the changes are reflected .
    417. 

  417. 

  418.  ![Browse production web app](./media/app-service-web-staged-publishing-realworld-scenarios/21umbpg.png)
    419. 

  419. 

  420. To learn more about how to use Courier, review the documentation .
    421. 

  421. 

  422. #### How to upgrade Umbraco CMS version
    423. 

  423. 

  424. Courier will not help deploy with upgrading from one version of Umbraco CMS to another. When upgrading Umbraco CMS version, you must check for incompatibilities with your custom modules or third party modules and the Umbraco Core libraries. As a best practice
    425. 

  425. 

  426. 1. ALWAYS backup your web app and database before doing an upgrade. On Azure Web App, you can set up automatic backups for your websites using the backup feature and restore your site if needed using restore feature. For more details, see [How to back up your web app](web-sites-backup.md) and [How to restore your web app](web-sites-restore.md).
    427. 

  427. 

  428. 2. Check if the third party packages you're using are compatible with the version you're upgrading to. On the package's download page, review the Project compatibility with Umbraco CMS version.
    429. 

    430. 

  430. For more details on how to upgrade your web app locally, follow the guidelines as mentioned [here](https://our.umbraco.org/documentation/getting-started/setup/upgrading/general).
    431. 

  431. 

  432. Once your local development site is upgraded, publish the changes to staging web app. Test your application and if all looks good, use **Swap** button to **Swap** your staging site to production web app. When performing the **Swap** operation , you can view the changes that will be impacted in your web app's configuration. With this **Swap** operation, we are swapping the web apps and databases. This means, after the SWAP the production web app will now point to umbraco-stage-db database and staging web app will point to umbraco-prod-db database.
    433. 

    434. 

  434. ![Swap preview for deploying Umbraco CMS](./media/app-service-web-staged-publishing-realworld-scenarios/22umbswap.png)
    435. 

  435. 

  436. The advantage of swapping both the web app and database:
    437. 

  437. 1. Gives you the ability to roll back to the previous version of your web app with another **Swap** if there are any application issues.
    438. 

  438. 2. For an upgrade you need to deploy files and database from staging web app to production web app and database. There are many things that can go wrong when deploying files and database. By using the **Swap** feature of slots, we can reduces downtime during an upgrade and reduce the risk of failures that can occur when deploying changes.
    439. 

  439. 3. Gives you the ability to do **A/B testing** using [Testing in production](https://azure.microsoft.com/documentation/videos/introduction-to-azure-websites-testing-in-production-with-galin-iliev/) feature
    440. 

  440. 

  441. This example shows you the flexibility of the platform where you can build custom modules similar to Umbraco Courier module to manage deployment across environments.
    442. 

  442. 

  443. ## References
    444. 

  444. [Agile software development with Azure App Service](app-service-agile-software-development.md)
    445. 

  445. 

  446. [Set up staging environments for web apps in Azure App Service](web-sites-staged-publishing.md)
    447. 

  447. 

  448. [How to block web access to non-production deployment slots](http://ruslany.net/2014/04/azure-web-sites-block-web-access-to-non-production-deployment-slots/)
    449. 

  449.