Tag: Azure DevOps

Deploying to Sitecore Managed Cloud

~ Nikhil Kulkarni ~ Leave a comment

Hi Champs,

As part of of Sitecore Managed Cloud blog series this my last blog for how to deploy to Sitecore Managed Cloud.

Without any further delay I will start with option which we have to deploy to SMC.

  1. Sitecore Azure Toolkit (SAT).
  2. Use Azure DevOps with TDS and Razl.

Sitecore Azure Toolkit (SAT):

To deploy your Sitecore solution onto Microsoft Azure®. The Sitecore Azure Toolkit simplifies the task of preparing and deploying a Sitecore solution with:

  • PowerShell commandlets to package a Sitecore instance into role-specific packages.
  • Default integration with Microsoft Azure services: Microsoft Azure SQL®, Microsoft Azure Redis Cache, Microsoft Application Insights®, Microsoft Azure Cognitive Search®.
  • Prebuilt ARM templates for frequently used topologies: XM, XP, XPSingle.
  • Configuration tweaks to run Sitecore on the Azure App Service.
  • Security features: HTTPS, low-privileged SQL access, secure Sitecore password.

Click here for more documentation for  getting started with Sitecore Azure Toolkit.

Use Azure DevOps with TDS and Razl:

There is another way which can be used is Configuring CI-CD pipelines in Azure DevOps by Using TDS web deploy packages. And for migrating the database use a Razl for first time. Let me explain this to you steps by step.

  1. Once you get SMC environments to use, you need to raise a ticket to Sitecore support for providing a services contract details for Azure DevOps which you are using.
  2. Once you get those details you need to configure that in your Azure DevOps account.
  3. Once Above is done you can use TDS to build and create web deploy packages pipeline.
  4. Once build pipeline is created then you can go further and create a release pipeline for the same.
  5. Now once entire setup is done you can have two option for getting your content (Sitecore data) migrated. The simple way is to sync everything to TDS and deploy, and the best way(recommended) is that use Razl to Sync all data for first time and then in subsequent release sync only required Sitecore data to TDS.

Summary: I found two ways to deploy the solution on SMC, but there are many different ways to do this. Please let me know in comment the other ways you guys used for deploying Sitecore on SMC.

Note: For using Razl please click here for link where great way described by Jon Jones.

Happy Learning!!!!

Advertisement

Configuring Azure DevOp’s Release Pipeline for TDS

~ Nikhil Kulkarni ~ 2 Comments

Hi Champs,

In this part, we are configuring the settings in the Release pipeline to deploy our Web Deploy package. Although the deployment can also perform as part of the build, we prefer separate steps for build and deployment to reduce the chance of accidental deployments to production environments.

The Release pipeline takes the build artifacts from the Build pipeline and installs them on the Sitecore instances that have been configured in Azure. There are a couple of ways we can do this. We can use the generated PowerShell Script, or we can use some of the built-in settings in Azure DevOps. The PowerShell script can be modified to work within complex build processes, but the deployment can be accomplished even without it.

Deploy to Azure using the built-in Azure DevOps settings

Azure DevOps comes with a built-in App Service deploy task, taking the Web Deploy package from the Build pipeline and installs it in the selected Web App. Keep in mind, there are a couple of important configuration settings here. We need to add the Azure subscription where the Web App is located and select it under the Azure subscription tab. This fills out automatically as part of the settings, and you’ll only need to select your subscription and App Service.

Window of Azure App Service Deploy

Deploy to Azure using the generated PowerShell Script

The second way of deploying the Web Deploy package to the Azure Web App is using the PowerShell script generated by TDS Classic. This can be useful in build servers where there’s no native support for Azure Web deploy, or when the user wants full control and use their release script. The script also gives you an easy-to-read log containing the item names and location in the Sitecore tree of the items.

To use it, we need the Publish profile file, which can be added in source control and made available for the Release pipeline the same way we made available the PowerShell script and the Web Deploy package.

We also need to create a PowerShell Script task in our Release pipeline. In it, we specify the path to the PowerShell script, generated by TDS and the arguments, required for executing it. The arguments are the same as the ones we used for deploying from our development machine.

WIndow of Powershell

Both ways of deploying will give you status about the deployment and a log with all the details. The logs are formatted a bit differently, so consider this when choosing which method to use.

Window showing logs

Summary

With TDS 5.8, we had the goal to simplify the deployment of the TDS project to Azure environments. Using Web Deploy packages, we were also able to reduce the deployment time while making the process more intuitive and visible for the developers.

Missed Part Two? Click here to read how to configure Azure DevOp’s Build Pipeline.

Need to start from the beginning? Click here to read how to set everything up locally.

Also do check my blog for automating slot swapping in Azure DevOps.

Happy Learning

Configuring Azure DevOp’s Build Pipeline for TDS

~ Nikhil Kulkarni ~ 3 Comments

Hi Champs,

In part one, we set up our TDS project to create a Web Deploy package and published the package to an Azure App Service manually. Now that we know we can deploy our Web Deploy package from our local environment, let’s continue by setting up an automated build in Azure DevOps. In this part, we’ll configure only the steps in the Build Pipeline, and publish the build drop (a Web Deploy package and a PowerShell script) to the Release pipeline. Note that this is a simplified scenario to be used as a starting point. Your build/deployment process might be more complex and can include different steps than this one. 

Configure the Build Pipeline

For the build pipeline, we will build the project in the “Release” configuration being it is the configuration we set up for Web Deploy packages. The first step while creating your new Build pipeline is to select your repository settings. In this example, we will use Git.

Window to Select Repository

We also need to add the TDS license; otherwise, our build will fail. This happens in the Variables tab of your Build pipelines. The following variables should be created with your license info in the values.

As a starting template for our Build pipeline, we can use the Azure Web App for ASP.NET template. We don’t need all of the predefined build steps in the template for this example, so we will remove some of them. This is done to simplify the example and focus on the build process.

Window to choose a template

Our build will contain the following tasks in the Build pipeline:

Window of Build Pipeline

Summary of the Tasks

This summary explains each task and the most important thing we should configure:

Use NuGet
This task specifies the NuGet version the build server will use. We can leave it with the default settings.

NuGet restore
This task restores the NuGet package and also doesn’t require any special settings to be configured. 

Build solution
We will set the Build solution task to build the Release configuration. The Platform and the Configuration parameters are configured from the build variables. The default values are “Release” and “Any CPU” so we can use them directly.
Window to set Build Solution

Copy Files to
The next step copies the build output to the Staging directory, so it’s ready for publishing. We only need the PowerShell Script and the Web Deploy package from our build drop, so we will only copy them. Side Note: the paths might be different for your build. 

Window to Copy Files

Publish Artifacts
The final step in the Build pipeline is to publish the build artifacts to the next phase: the Release pipeline.

Window to publish the build artifacts

Once we have everything configured, we can run a test build. If everything is configured properly, we will see the Web Deploy package and the PowerShell script available in the Artifacts explorer in Azure DevOps.

Window of Artifacts Explorer

Summary

As shown above, setting up a build in Visual Studio online to create a Web Deploy package is relatively simple. The only real customization of the build was a step to pick up the files from the build folder and add them to the Artifacts folder. In the next part of the series, we will show you how to configure a release pipeline to deploy the Web Deploy package to an instance of Sitecore running on an Azure App Service.

Missed the first part? Click here to read Part 1.

Ready to continue to the next step? Click here to move on to Part 3.

Happy Learning

Setting Up TDS to Build Azure Repo

~ Nikhil Kulkarni ~ 2 Comments

Hi Champs,

In next few blogs I going to explain you setting up TDS for entire Sitecore CI-CD process. Without any further delay we will start by below.

By using TDS 5.8 and Web Deploy packages, I’ll walk you through on how to create a fully automated build and deployment process from your workstation to source control and into your Azure environment.

The TDS Web Deploy packages were designed around quick and easy deployments to Azure, but they can be deployed to any Sitecore server that supports Web Deploy.

The difference in using .update packages and Web Deploy packages 

Workflow before TDS 5.8
Chart showing deployment before TDS 5.8

Workflow after TDS 5.8

Chart showing deployment process with TDS 5.8

Setting up the TDS project for Web Deploy

The Web Deploy Package tab has similar options to the Update package tab. You can enable building a Web Deploy package, what to include in the package, and the package name. In this example configuration, we’ll need a Web Deploy package, so we’ll check off “Build web deploy package.” The name can be left blank, and it will use the name of the project.

Window showing Web Deploy Package Tab

Since we are planning to build on the cloud based VSO build server, we need to add the TDS Build components NuGet package into the TDS project. To do this, you need to execute the following command in the Package Manager Console of Visual Studio. Side note: make sure you have selected the nuget.org repository while executing this command.

Install-Package HedgehogDevelopment.TDS -Version 5.8.0.6

Building the Web Deploy package

To create the Web Deploy package, simply build the project/solution with the configuration where Web Deploy packages are enabled. When the build is finished, you will find a folder called [Configuration]_WebDeploy with the Web Deploy package and the Web Deploy PowerShell script.

Image showing Publish Web Deploy and TDS Project files

Please note: the PowerShell script provided by TDS isn’t the only way to install the package. It is provided as a convenience for the developer to help them deploy the package if they don’t have another method of deploying it. It also contains script that can be used to monitor the deployment on the server.

Testing the Web Deploy package

Once you have the Web Deploy package and the PowerShell script, you only need to specify where it should be deployed. This can be easily set using a Publish Profile from Azure or by using parameters to the PublishWebDeploy.ps1 script. You can get a publish profile from the control menu of the App Service in Azure.

control menu of App Service in Azure

Now you can make a test deployment to the Sitecore instance using the script. I placed my Publish Profile file in the same directory where the Web Deploy package and the script were generated.

If you want to deploy the Web Deploy package into your Azure instance, all you need is to execute the script using the following parameters:

PublishWebDeploy.ps1 -PackagePath TDSProject1.wdp.zip -PublishSettingsPath tdstestinstance-630820-single.PublishSettings -ViewLogs

Summary

This completes the setup of the TDS project for building Web Deploy packages. Soon, I’ll walk you through on how to set up a TDS build in a Visual Studio Online Build Pipeline.

Ready to move on to the next step? Click here to read about configuring Azure DevOp’s Build Pipelines.
 
 
Happy Learning

Sumo Logic integration with Sitecore Azure PaaS

~ Nikhil Kulkarni ~ Leave a comment

Hi Champs,

Today I am going to take you to the new product called Sumo Logic which we can integrate with Sitecore Azure PaaS for better log management.

Before starting you may have below two questions.

What is Sumo Logic?

Sumo Logic is a cloud-based machine data analytics company focusing on security, operations and BI use-cases. It provides log management and analytics services that leverage machine-generated big data to deliver real-time IT insights

Why Sumo Logic?

As per my experience Sumo Logic is coolest tool I ever seen for Log Management and monitoring. It gives a GUI based Live log management system by which you can track everything and not losing your time for checking logs from files. One more advantage is it alerts you one basis of exception captured in Log.

We will move without killing more time to the steps of configurations which are as below. Note all below steps you need to perform against your Sitecore Azure PaaS resource group.

Step 1. Configure Azure storage account

In this step you configure a storage account to which you will export monitoring data for your Azure service.

If you have a storage account with a container that you want to use for this purpose, make a note of its resource group, storage account name and container name and proceed to Step 2.

To configure an Azure storage account, do the following:

  1. Create a new storage account General-purpose v2 (GPv2) storage account. For instructions, see Create a storage account in Azure help.
  2. In the Azure portal, navigate to the storage account you just created (in the previous step).
  3. Select Blobs under Blob Service.
    Make a note of the container name, you will need to supply later in this procedure.

    1. Select + Container,
    2. Enter the Name
    3. Select Private for the Public Access Level.
    4. Click OK.

Step 2. Configure an HTTP source

In this step, you configure an HTTP source to receive logs from the Azure function.

  1. Select a hosted collector where you want to configure the HTTP source. If desired, create a new hosted collector, as described on Configure a Hosted Collector.
  2. Configure an HTTP source, as described on HTTP Logs and Metrics Source. Make a note of the URL for the source, you will need it in the next step.

Step 3. Configure Azure resources using ARM template

In this step, you use a Sumo-provided Azure Resource Manager (ARM) template to create an Event Hub, three Azure functions, Service Bus Queue, and a Storage Account.

  1. Download the blobreaderdeploy.json ARM template.
  2. Click Create a Resource, search for Template deployment in the Azure Portal, and then click Create.
  3. On the Custom deployment blade, click Build your own template in the editor.
  4. Copy the contents of the template and paste it into the editor window.
  5. Click Save.
  6. On the Custom deployment blade, do the following:
    1. Create a new Resource Group (recommended) or select an existing one.
    2. Choose Location.
    3. Set the values of the following parameters:
  • SumoEndpointURL: URL for the HTTP source you configured in Step 2 above.
  • StorageAccountName: Name of the storage account where  you are storing logs from Azure Service, that you configured in Step 1 above.
  • StorageAccountResourceGroupName: Name of the resource group of the storage account you configured in Step 1 above.
  • Filter Prefix (Optional): If you want to filter logs from a specific container, enter the following, replacing the variable with your container name: /blobServices/default/containers/<container_name>/
  1. Select the check box to agree to the terms and conditions, and then click Purchase.

Azure_Blob_Storage_Custom_Deployment.png

  1. Verify the deployment was successful by looking at Notifications at top right corner of Azure Portal.

notification-success.png

  1. (Optional) In the same window, click Go to resource group to verify the all resources were successfully created, such as shown in the following example:

Azure_Blob_all-resources.png

  1. Go to Storage accounts and search for sumobrlogs, then select sumobrlogs<random-string>.

storage-accounts.png

  1. Under Table Service do the following:
    1. Click Tables.
    2. Click + Table.
    3. For Name, enter FileOffsetMap.
  2. Click OK.

Azure_Blob_create-table.png

Step 4. Push logs from Azure Service to Azure Blob Storage

This section describes how to push logs from an Azure service to Azure Blob Storage by configuring Diagnostic Logs. The instructions use the Azure Web Apps Service as an example.

  1. Login to the Azure Portal.
  2. Click AppServices > Your Function App > Diagnostic Logs under Monitoring.
  3. You will see the Diagnostic Logs blade. Enable Application Logging, Web Server Logging, or both, and click Storage Settings.
  4. Select the Storage Account whose connection string you configured in Step 1.
  5. In the Containers blade, select the container you created in Step 1.
  6. In the Diagnostic Logs blade, specify the Retention Period (Days), and click Save to exit Diagnostic Logs configuration.export-webapp-logs.png

Happy learning and innovating Sitecore.

Automating Deployment Slot Swapping for Sitecore Azure PaaS

~ Nikhil Kulkarni ~ 1 Comment

Hi Champs,

Today I am going to introduce you to the steps which you can use to swap deployment slots for production environment automatically in release pipeline by small manual intervention for approval/resume. Below are the steps which will help you to set-up slot automation.

Given any scenario this will work, but in my case it is like below.

I have release pipeline stetted up according to the environments.

Configuring slot swaps in Production

The Dev and QA environments orchestrate whatever flow you want in those environments (e.g. provision using ARM, deploy, run functional tests, run load tests etc.), and in this example don’t have any slot specific activity. Therefore let’s take a look at the production environment tasks itself directly:

(I’ve kept this to a minimum to keep it clearer, so no provisioning, running scripts or other activities.)

First deploy the web application to the staging slot in the production environment using the Azure App Service Deploy task:

Check the Deploy to slot option in the standard task, and then choose the Slot (I called the slot “staging” but you can use any name).

Next I’ve added an Agentless phase as it’s not going to delegate any actions to an agent, and added a Manual Intervention task. This causes the flow to pause until the manual intervention is completed by the specified approvers (groups and/or individuals). If it’s approved then it carries on, if it’s rejected (or times out and therefore is rejected) then the flow stops. In this case that works for me as I want the staging environment to be manually verified and then signed off as ok for final release to production. If it gets rejected then it never gets promoted from staging to production.

Finally, if the staging slot has been manually verified and is ready to be used, then we can initiate the actual slot swap (in an agent phase) using the Azure App Service Manage task:

The staging and production slots will then be swapped over, leaving the old production version in the staging app and the latest version in the production slot.

This flow supports the actual slot swaps being automated, but with manual approval. A nice side effect of the slot swap is that should there be a problem, the slot swap can be reversed to redeploy (rollback) the old version of the app now in the staging slot.

Happy Learning/Innovating Azure.

Working with Sitecore Managed Cloud

~ Nikhil Kulkarni ~ 1 Comment

Hi Champs,

Today I am going to share my experience of working with Sitecore Managed Cloud from scratch. In my scenario, it was fresh website deployment on Sitecore Managed Cloud offering which I will split this is below section to make it better. Sorry but this is a bit lengthy and theoretical article which may get boring but reading this article will give you a better understanding of working practically with Sitecore Managed Cloud.

Engaging the Customer:

In this process, you need to agree with Customer and Sitecore that you will be using this offering from Sitecore. For that Sitecore Team and you need to list down the benefits like below for this offering.

  1. Service availability is managed by the Sitecore team.
  2. Sitecore Managed Cloud Team will be responsible to set entire infrastructure.
  3. Depending on traffic/expected traffic Sitecore Managed Cloud team suggests the Scaled environment topology be used in the Production environment.
  4. Sitecore Managed Cloud team will be monitoring the activities and report any unwanted incident happens and try to help the Partner team to work on that exact point to make sure that nothing is going wrong.

Step-in to procure:

In this process Customer and Partner team has to sign an agreement and procure the Sitecore Managed Cloud services and also add it to Sitecore License. At the same time Partner and Customer has to also need to provide information about different modules that are used in the implementation so that Sitecore License will have all the necessary conditions applied to it. Once this is done Sitecore Managed Cloud team will assign a ticket to Client for feeling the same information and some more information. This ticket will have table which you guys need to fill for information like including things like Solr/Azure search, EXM, JSS, and different modules if applicable. After this Sitecore Managed Cloud team will commission environments like (Dev, QA, Prod)  as mentioned by you with all the credentials details.

Set-up Azure DevOps:

This process is a bit useful for developers and DevOps guys. You need to follow the below steps.

  1. Create a release pipelines according to branches and strategies.
  2. Once this is done when now you need to change the subscriptions and resources to Sitecore Managed Cloud.
  3. For above you need to add Service Connection for your Azure DevOps.
  4. To get service connection you need to create a Sitecore Ticket so that Sitecore Managed Cloud team will create Service Connection and will share the details to you.
  5. Onccce that is in place you need to create Service Connection in you Azure DevOps and apply right Subscriptions and resources to right task and jobs in pipelines according to environments.
  6. Now you are ready for a fully automated Sitecore System and can deploy everything step by step on respective environment and test the implementation.

Note:

  1. In Sitecore Scaled environment you will get different web apps for each service like cm, cd, processing, redis, xConnect, xcSearch, and others.
  2. As Solr comes as a different Cloud offering in Sitecore Managed Cloud so that will be partially maintained by Sitecore Managed Cloud team but for more information on this you can check with Sitecore itself.
  3. While implementing this if you face any issues you need to follow same process of raising the Sitecore support ticket to get solutions.
  4. For escalations and different leadership help, Sitecore assigns a Customer Success Manager for this offering which is a great help from Sitecore.

Happy Learning Sitecore…..