Перейти к содержимому

While this guide is primarily targeted towards usage with Azure Web apps and Sitecore ASP.NET solution deployed on them, still it is possible to use it on on-premise solution with other types on ASP.NET projects, running on Windows.

Reasoning behind this

Why I actually started building all this thing up, ignoring interesting Helix publishing pipeline or dropping idea of storing source and transformation files in my source control?

In Helix publishing pipeline I do not like the fact that I could not use different transformation based on roles, where I am deploying (if it is there - can you point it to me?).

When storing vanilla config in source control - I do not like the fact that I will need to update it when I am updating Sitecore version (hence, merging and solving possible conflicts).

Solution

So, I decided to build this transformation thing anew, almost from scratch. I used the same idea as used in Helix publishing pipeline: store only transformation files under source control, as, in general, they are generic. Also, I agreed on following naming convention:

  • configFileName.config.xdt - transforms config file with name configFileName.config lying at this path for all environments
  • configFileName.config.xdt.roleName - transforms config file with name configFileName.config lying at this path when deploying this particular role

That's is a script, which could be uploaded to web app and executed via Kudu. Script wants several parameters:

  • folderWithTransforms - folder, where all transform files are residing
  • webRoot - folder, where webRoot could be found
  • roleName - optional, if there is a specific tranformations for this particular role
  • transformationAssemblyPath - if Microsoft.Web.XmlTransform.dll is not at the same path as script

The target of this post is to share how to configure Sitecore JSS headless with a Node.js proxy on CentOS and to demonstrate a staging approach for the hosting of the CD role. Since the front-end is rendered on a stand-alone Node proxy, we can easily configure as much backend CD servers as needed, which allows us to deploy CD code on a staging server, and then switch the target server on the Node instance.

...читать далее "Sitecore JSS: a blue green Node.js server configuration"

While working with Sitecore deployments based on ARM and PowerShell scripts, developed by Rob Habraken (Rob has covered them in a series of blog posts on his own blog) and slightly optimized by me, I noticed that we are having a problem: these scripts are used on a per-project basis and once implemented, they start aging. Since manually updating scripts for each project is a dull and cumbersome task, it usually is never executed. So I decided to build a VSTS release task, which could be reused in each of our projects and makes it easier to always have the latest version of the ARM and PowerShell scripts for a certain Sitecore version.

...читать далее "Sitecore Deployer"

Since I started working with Azure Web apps I started thinking: how could we optimize budget spending for PaaS? For VMs it is clear, you stop them. VM v1 requires an additional PowerShell command to deprovision them to stop spending money on them, while VM v2 are deprovisioned automatically on stop. But for or Azure SQL databases and Azure Web apps it was not that straightforward.

...читать далее "Saving money with Azure Costs Saver VSTS extension"

Start of it 
Some time ago, my colleague Jeroen asked me to optimize the local development process for one of our web applications, which has more than 450 C# MVC views, which leads to a problem – extremely long local startup times (can be more than 5 minutes on decent developer workstation). Also, we’ve experienced the same problems on production, which is delivered by means of MsDeploy (though they are not so big, cause delivery to production is much rarer event than local compilation). So, I set sails on investigation and optimizing this

...читать далее "Road to precompiled web application based on Umbraco CMS"

Данная запись посвящена решению следующей задачи: автоматически развернуть веб приложение, основанное на Drupal, с компиляцией фронтэнда, использующей Grunt, при помощи Continuous Deployments фичи Azure Web app (то есть, без выделенного билд сервера), при том, что доступ к серверу должен быть ограничен по IP.

...читать далее "Azure Web apps: автоматическое развертывание Drupal с фронтэнд компиляцией при помощи Grunt"

This is one more piece of automation puzzle to save time and make the life of a build engineer easier. This part is targeted towards removing double work of redoing things that are already done on  Teamcity level configurations of Umbraco-driven Continuous Delivery (CD) projects.

...читать далее "Automated umbracoSettings.config modifications"