I’ve just started setting up some continuous deployment for my personal websites. All of the sites are hosted within Azure App Services and the sources are located on either GitHub or BitBucket. By having the source code located on a public accessible repository (be it private or public), it’s rather easy to connect Azure to these locations.

On my day-job I come across a lot of web- and desktop applications which also need continuous integration and deployment steps in order for them to go live. For some of these projects I’ve used Octopus Deploy and currently looking towards Azure Release Management. These are all great systems, but they offer quite a lot of overhead for my personal sites. Currently my, most important, personal sites are so called static websites using MiniBlog (this site) and Hugo (for keto.jan-v.nl). Some of the other websites I have aren’t set up with a continuous deployment path yet.

I don’t really want to set up an Octopus Deploy server or a path in Azure Release Management for these two sites. Lucky for me, the Azure team has come up with some great addition in order to provide some custom deployment steps of your Azure App Service. In order to set this up, you need to enable the automatic deployments via the `Deployment Options` blade in the Azure portal.

image

Normally, when you have set up your site to be deployed every time some change occurs in a specific branch of your repository the Azure App Service deployment system tries to build your site and place the output to the `wwwroot` folder on the file system. Because I don’t need any msbuild steps whatsoever, I need to override this step and create my own, custom, deployment step.

Setting up such a thing is quite easy, you just have to create a `.deployment` file in the root of your repository and specify the build/deployment script which should be executed. This functionality is provided by Kudu, which Azure uses in order to deploy Git repositories to the Azure App Service.

You can specify a custom script in this deployment file, this can either be a ‘normal’ command script (cmd or bat) or a PowerShell script. I have chosen for PowerShell as it offers me a bit more flexibility compared to a normal command script.

The contents of the deployment file aren’t very exciting. For my scenario it looks like the following:

[config]
command = powershell -NoProfile -NoLogo -ExecutionPolicy Unrestricted -Command "& "$pwd\deploy.ps1" 2>&1 | echo"

This will activate the custom deployment step within the Azure App Service as you can see in the following picture (Running custom deployment command…).

image

 

The contents of my PowerShell script, deploy.ps1, aren’t very exciting either. The MiniBlog project is just a normal ASP.NET Website, so I just have to copy the contents from the repository folder to the folder of the website.

robocopy "$Env:DEPLOYMENT_SOURCE\Website" "$Env:DEPLOYMENT_TARGET" /E

You can do some more advanced stuff in your deployment script. For my Hugo website I had to tell the Hugo assembly to build my website. So the contents of this deploy.ps1 script are similar to this.

# 1. Variable substitutions
if ($env:HTTP_HOST -ne "") {
    echo "doing substitutions on $Env:DEPLOYMENT_SOURCE\config.toml"
    gc "$Env:DEPLOYMENT_SOURCE\config.toml" | %{ $_ -replace '%%HTTP_HOST%%', $env:WEBSITE_HOSTNAME } | out-file -encoding ascii "$Env:DEPLOYMENT_SOURCE\config.new.toml"
    mv "$Env:DEPLOYMENT_SOURCE\config.toml" "$Env:DEPLOYMENT_SOURCE\config.old.toml"
    mv "$Env:DEPLOYMENT_SOURCE\config.new.toml" "$Env:DEPLOYMENT_SOURCE\config.toml"
    rm "$Env:DEPLOYMENT_SOURCE\config.old.toml"
} else {
    echo "not doing any substitutions"
}

# 2. Hugo in temporary path
& "$Env:DEPLOYMENT_SOURCE/bin/hugo.exe" -s "$Env:DEPLOYMENT_SOURCE/" -d "$Env:DEPLOYMENT_TARGET/public" --log -v

# 3. Move the web.config to the root
mv "$Env:DEPLOYMENT_SOURCE/web.config" "$Env:DEPLOYMENT_TARGET/public/web.config"

Still not very exciting of course, but it shows a little what can be achieved. I’m not aware of any limitations for these deployment scripts, so anything can be placed inside it. If you need to do something with specific assemblys, like the hugo.exe, you will need to put them in your repository, or some other location which can be accessed by the script.

You can also view the output of your script in the Azure Portal. All data which is outputted by the script (Write-Host, echo, etc.) is shown in this Activity Log.

image

Useful when debugging your script.

If you have any secrets in your web application/site (like connection strings, private keys, passwords, etc.), it might be a good idea to use this custom deployment step to substitute the committed values to the actual values. If these values are stored in the Azure Key Vault, you can just access the key vault and make sure the correct values are placed within your application before it’s deployed.

Using these deployment scripts can help you out when you have some simple scenarios. If your system is a bit more complex or are working in a professional environment, I’d advise to check out one of the more sophisticated deployment systems, like Octopus Deploy or Azure Release Management. These systems offer a quite a bit more options out of the box and it’s easier to manage the steps, security and insights of a deployment.

Next I’ll try to update an Umbraco site of mine to make use of this continuous deployment scenario. This should be rather easy also as it only needs to call msbuild, which is the default action the Azure App Service deployment option invokes.

When doing modern web development you will probably have to start using NPM sooner, rather than later. Not a big deal of course, since it’s a great addition to the frontend development environment.

However, most NPM packages have quite a bit of dependencies to other packages. All of these dependencies get pulled towards your system also. Still not a big problem as you want a working solution.

The problem arises when you are on a Windows environment, there are a lot of dependencies and you want to delete a project folder on your system. You will stumble across the fact that Windows has a rather low limit on how long a path can be. When all dependencies are loaded, you will probably have some paths which are too long for Windows to handle properly.

This will give you quite a bit of a problem as you can’t delete the folder(s) anymore. One way of solving this is by using PowerShell. By executing the following script you will be able to delete the NPM modules in your project.

ls node_modules | foreach {
	echo $("Deleting module..." + $_.Name)
	& npm rm $_.Name
}

This will iterate through the `node_modules` folder and remove each module inside it.

The output will be something like this:

Deleting module...grunt-contrib-uglify
Deleting module...karma

Do note, this only works for NPM folders. If your path is too long because of some other reason, you’ll have to think of something else.

As of late I’ve started using the VMWare products for virtualizing my development environments again as a replacement for Hyper-V.

Today I wanted to access some files of my virtual machine on the host in order to write a blog post on some code I had saved in there. The VMWare disk files are stored as a VMDK file and it’s not possible to mount these type of files in Windows like a VHD file.

In order to mount a VMDK file you’ll need some third party software. Most people tell you to download the VMWare Disk Mount Utility (note the date: 2005-11-29). This probably was a valid solution back in the day, but it appears this software isn’t compatible with the recent versions of the Microsoft Windows operating system.

When installing the VMWare Disk Mount Utility I’m receiving the following event when checking out the event viewer:

Windows Installer installed the product. Product Name: VMware DiskMount Utility. Product Version: 1.00.0000. Product Language: 1033. Manufacturer: VMware, Inc.. Installation success or error status: 1603.

While troubleshooting this error you’ll probably stumble across the following KB article which tells you to set the appropriate security permissions on the Program Files folder. I’ve tried setting these permissions for both the SYSTEM account as the Administrators group, but to no avail. So I think it’s safe to assume this software doesn’t work properly anymore.

I did find some other piece of software from PassMark, called OSFMount. This piece of software installed like a charm and it’s capable of mounting VMDK files also.

When staring up the application you’ll see a very self explanatory screen.

image

Just push the Mount new… button and you’ll be prompted to select the appropriate image file.

image

After selecting the VMDK file I did have to explicitly select the partition which I was in need for. When I selected the option Use entire image file Windows notified me it wasn’t able to do something with the new disk and I should format it.

image

Once selected all data on the earlier screen will get updated appropriately and you’ll be ready to use the newly mounted disk.

image

In my case the mounted disk is automatically added to the Windows Explorer list of disks.

image

It’s too bad the OSFMount software isn’t high on the search index yet. Hope this post will help a bit.

With Windows 10 we’ve gotten a lot of nice little features which help us modifying the theme. There is however 1 option which the team hasn’t implemented (yet). The option to select different wallpapers for all of your connected displays.

I’m working with a triple monitor setup at home and at work most of the time with a dual or also a triple setup. Of course I don’t really need different wallpapers on all of my monitors, but it’s a nice feature.

Luckily we are still able to do this, using the ‘old’ control panel pages which are still available in Windows 10. If you type in the following command inside a Windows Explorer address bar or the Run command window you’ll be able to get there.

control /name Microsoft.Personalization /page pageWallpaper

image

On this screen you are still able to select your wallpaper for every connected display.

image

Just a little tip, hope it helps.

While I was setting up a VPN connection to my Azure Virtual Network I wanted to uncheck the option to use the Default Gateway of the connected network. Normally you’d do this by clicking on the `Properties` button of the selected protocol.

image

However, there appears to be a bug in Windows 10 and VPN connections for this button which causes the Properties window not to appear.

I have solved this with the help of Todorovic Dragan’s post about this matter. Over there he states you can change the `Default Gateway` setting manually.

Just navigate to the folder `C:\Users\[YourUsername]\AppData\Roaming\Microsoft\Network\Connections\Pbk` and open the file rasphone.pbk file in your favourite text editory.

This file contains all configuration settings of your dial-in connections, like VPN’s. Search for the configuration block of your connection. For me it’s [janhome_manual] and change the option IpPrioritizeRemote to 0.

Changing this setting will disable the checkbox for using the gateway of the remote network.