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
Данная запись посвящена решению следующей задачи: автоматически развернуть веб приложение, основанное на Drupal, с компиляцией фронтэнда, использующей Grunt, при помощи Continuous Deployments фичи Azure Web app (то есть, без выделенного билд сервера), при том, что доступ к серверу должен быть ограничен по IP.
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.
Я – большой фанат TeamCity, автоматической доставки, развертывания и любой автоматизации. Как правило, я имею дело с доставкой разработанных нами приложений, но в данном посте речь пойдет о доставке дополнительного функционала в “чужое”, “коробочное” веб-приложение, развернутое на нашем сервере.