SonarQube is awesome tool and it's Community edition (which is free) fulfills almost everything one could dream for in the world of static code analysis. But, you could not analyze PR's with it by default and have to pay for at least Developer edition. Further you could find my attempt to overcome this limitation (it fulfills MY goals and seems to be worth sharing with broader audience)....читать далее "SonarQube Community edition and PR analysis"
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....читать далее "Transforming deployed configuration file in Azure web app"
Azure DevOps does a great job when providing hosted agent services. They come loaded with all required software, they care about updates and everything else, but they have some major drawbacks:
- No static external IP-address (so it's not possible to have an additional layer of security))
- You get a new VM each time, so you need to clone your repository fresh, install a fresh set of NPM packages, install all those base Docker images (not a big deal for alpine-based images, but when it comes to Microsoft one, it is really a hitter)
- For closed source projects there is a hard limit of 1800 minutes per month per 1 hosted job (I do not like limits even if I never hit them 😀 )
- And so on – you name it
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.
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.
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.
This blog post covers automation of VSTS extension publishing with Teamcity 🙂
Recently, my colleague asked to help him in configuring trust relationship with self-signed certificate on his development laptop. It took decent amount of Googling to find and build this. ...читать далее "Trusted self-signed certificate on local Windows machine"
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