Month: November 2019

My Sitecore 2019 Contributions

~ Nikhilkulkarni ~ 1 Comment

Hi Champs,

I am writing this blog to share what I have done in year 2019, not only in Sitecore but in other tech communities also.

Year 2019 has been a very experimental year for me as at the start of the year I was working in Organization for Sitecore one of the huge/large scale Sitecore implementation. I was working as Sitecore SME/Architect there. As I was Client to Sitecore, I got a chance to speak with some great tech brain in Sitecore.

Suddenly one I got a call that you got selected and, I got a chance to move to Auckland thanks to my current Organization for this. After moving in New Zealand again I started to play with Sitecore and this time Sitecore with Azure PaaS.

Now coming back to what I have done so for Sitecore and other technologies.

Working with Sitecore:

I will take this as questions and try to answer.

How you are contributing to Sitecore from online platforms?

Answer to this question would be simple and that is– I have Modules in Sitecore Marketplace, I write a blogs, I have few Open projects in Git, I am active member of Sitecore StackExchange etc. So I will quickly give a summary via points to all this contributions as below.

  • Sitecore Market Place:

The main medium for sharing the new customized things for Sitecore is Sitecore Marketplace. I have below Modules Published in Market Place.

  1. Social Side Menu: https://marketplace.sitecore.net/en/Modules/S/Social_Media_Side_Menu_Module.aspx
  2. Sitecore NFR: https://marketplace.sitecore.net/en/Modules/S/Sitecore_NFR_Module.aspx
  3. Sitecore IoT: https://marketplace.sitecore.net/en/Modules/S/Sitecore_IoT_ModuleArduino.aspx
  4. Sitecore Fake SMTP: (Documentation for this module is in progress)    https://marketplace.sitecore.net/Modules/S/SitecoreFakeSMTPModule10.aspx
  • Blog:

The main medium for sharing knowledge is via blogs, I try to share my knowledge and different achievements over here in blogs so that those who are finding answers to those question they can get it easily.

  • Git:

https://github.com/NKulkarni92

I have repo where I have code for all the above modules and I also have few Open projects for Sitecore in Android which I am currently working on.

  • Sitecore StackExchange:

The other main medium for sharing knowledge is via Stackexchange, I try to share solution which is good fit for the questions which we get in the exchange I also try to follow best practice within Solution if it is related to code or configuration.

stack

  • LinkedIn:

I have almost near to 2K connection here with different technology, I try to answer the questions which are asked here in LinkedIn for Sitecore also. But I mainly getting questions on chatbox here where I answer privately.  I also share knowledge at one of the groups created by Chris Williams for Sitecore DAM. I discussed how IoT helps to build the DAM in new era.

For this year, I’ve been working on different projects related to Sitecore. But each project complexity differs. So, with the different projects, I’ve been able to acquire experience but also to use new Sitecore features.

How you are contributing to Sitecore from offline platforms?

My offline activities haven’t changed. I keep on learning new ways, best practices on Sitecore. I am going to perform 1 presentation about the Sitecore Managed Cloud On-Boarding in SUG Auckland on 5th December 2019. I also help beginners in the team to learn Sitecore. As a part of CoE team I also help different teams to train then and setting up the environments for them according to their client’s needs. I am also involved in sales of products technically where I do tech pre-sales PoC for different Sitecore offerings. I also do freelance or volunteer consulting with different offline clients.

What is you experience with different new features of Sitecore?

I have little different experience with new Sitecore features like JSS, SXA,  new Sitecore Managed Cloud, Sitecore on Azure PaaS, as I said different then I will explain one example here is like JSS.

I worked on hacking JSS in Sitecore 8.2 version  and then we migrated the entire Site to Sitecore 9.2 for one of my client.

One more different experience is fine tuning website migrated from AWS IaaS to Sitecore Managed Cloud. But to explain few of my project related to these experiments I made point wise details as below.

SXA

This is the basic development whereby we had to get content architecture which will help to accommodate 1500+ SXA Multisites to the major global rollout.

Difficulty level: Extreme – Need to know how Sitecore works internally.

JSS

I created a dummy project in JSS just to get the idea of how it works internally. This was the reverse engineering which I have done actually to get one of my Sitecore 8.2 website upgraded to Sitecore 9.1.1 JSS website. In actual implementation we went with disconnected architecture to get everything resolved and now the Site is live. We used Native JSS as OOTB and React for the JSS app.

Sitecore Managed Cloud

This was one of the complex projects where I worked on migrating Sitecore site from AWS to Sitecore Managed Cloud offering. This is the first Sitecore Managed Cloud Project in New Zealand. The client is very happy with what we have achieved as the load time for Site is less than 2sec which is amazing. Working with the Managed Cloud team is great experience.

Other projects

I have also been involved in projects where we have used the Sitecore PaaS, work on presales for the client to get then on Sitecore 9.2 SXA with Sitecore Managed Cloud and Sitecore Commerce. Also working on different ongoing projects to get new features developed for them.

All the projects I’ve been involved in, I have tried to share my experience via blog posts or by performing presentations.

What are your future Objectives?

I will try to answer this in bullets as below.

  1. I will try to contribute more to all Sitecore community mediums.
  2. I am already in process of me next Sitecore Module.
  3. I am in panning phase of mobile based app for Sitecore which I will try to complete in coming year.
  4. Rather than just promoting Sitecore I am trying to sell new feature of Sitecore so that implementations of website will be more code less and Client will get full authority on what they want to do in Sitecore.
  5. Be a part of technical presales.
  6. I am trying to get Sitecore more into AI and IoT space for which I will be working throughout next year.
  7. I will be sharing the new learning and innovative things via my blogs to community.
  8. Keep learning Sitecore

Now this is a small contribution to Sitecore but I have few different things in my buckets as below.

Working with Azure DevOps/PaaS.

I finally managed to work with Azure this year as I was working only in premise VM’s, I badly wanted to work with Cloud and year 2019 given me this opportunity.

I learnt most of the  things like deploying .net web applications in Azure PaaS, creating and managing ARM template in Azure, Resource creation and managements, up scaling and down scaling in Azure, Performance tuning in Azure PaaS.

I also played around to create few Azure DevOps pipelines this years with total automation in workflow manner to push everything from source control system to running environments.

I decided to share what I got in Azure via my blogs and I already shared few and few are in pipelines to get published.

Working with Arduino

Yeh year 2019 asked me to go back and get this again in plate to eat. yes Arduino one of the best IoT platform to code and automate the things with IoT devices. In year 2014 I was playing around with Arduino on extensive level to get one of my university level project completed, but year 2019 asked me to play around with this to follow my passion about all these electronic/robotic kits. I started writing codes to Arduino AWS community IDE which is basically closed group for Arduino programmer where you can write code for Arduino and share within community and help them. I have 4 different sketch in Arduino right now and working on few more.

Happy Sharing,  Happy Learning

Advertisement

Configuring Azure DevOp’s Release Pipeline for TDS

~ Nikhilkulkarni ~ 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

~ Nikhilkulkarni ~ 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

~ Nikhilkulkarni ~ 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

Higher thread usage in Sitecore Azure PaaS

~ Nikhilkulkarni ~ Leave a comment

Hi Champs,

Today I am going to explain one of the major factor which can contribute to issue of Performance to your Sitecore Application in Azure PaaS, which is excessive thread calls. Below are point wise explanation of entire case study with solution.

The actual trigger for Higher thread Usage: 

Calling an async code in a synchronous execution path leads to the calling thread being paused until the async part finishes (the corresponding Task object is marked as completed). Because of the specific implementation of async methods in C#, the Task object cannot be marked as complete until continuations are executed. In most of the scenarios, continuations are scheduled to be executed on thread pool threads. Therefore, the calling thread starts to depend on the availability of worker threads in the default thread pool.

One more contributor xConnect:

Sitecore xConnect is written according to high-performance application best practices, with optimized thread consumption. Its design allows for taking full advantage of async operation processing and it defines the custom scheduler to tackle excessive thread consumption.

So now you will be wondering that in regular development path we have both the above case will come, then why this issue started coming from Sitecore 9XP onward.

Simple answer(Root Cause of the issue):

Unfortunately, the recent changes in .NET Framework 4.7.2 (System.Net.Http assembly) removed the respect of custom thread schedulers. This has led to excessive thread consumption by sync-async operations.

Solution:

It is possible to configure a Sitecore application to use a previous version of the System.Net.Http.dll assembly instead of the .NET Framework 4.7.2 version.

Copy the System.Net.Http.dll file from the C:\Program Files (x86)\Microsoft Visual Studio\[*]\Professional\MSBuild\ Microsoft\Microsoft.NET.Build.Extensions\net471\lib folder to the \bin folder of Sitecore. Assembly file version 4.6.26011.01.

      – where [*] should be replaced with relevant Visual Studio version (2017 or 2019).

Configure Sitecore to use the new assembly version instead of the assembly from GAC:

  1. Remove all existing binding redirects for System.Net.Http from the Web.config file.
  2. Add the following binding redirect to the Web.config file: 
    <dependentAssembly>
  <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" xmlns="urn:schemas-microsoft-com:asm.v1" />
  <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" xmlns="urn:schemas-microsoft-com:asm.v1" />
</dependentAssembly>

When version 4.2.0.0 of System.Net.Http library is used, it contains an implementation of the HttpClient class that respects custom schedulers. Therefore, synchronous methods of xConnect client require just a single thread to complete a request.