Productivity

Improved init.ps1 for Sitecore Container Development

If you're working with Sitecore containers, chances are you're also using the init.ps1 script to set up the local environment. Read on to learn how we improved it.

Reto Hugi

Sep 30, 2021 • 3 min read

If you're working with Sitecore Containers, chances are you're also using the init.ps1 script from the Getting Started repo by Sitecore to initialize your local development environment. So did we. After a few months we came up with small improvements to simplify and speed up our workflow with the init.ps1 script.

Features of the init.ps1 Script

Before we dive into the improvements, let's see what the default init.ps1 actually does for us:

It let's us provide the path to the license.xml, define the SQL SA and Sitecore Admin password.
It checks if the SitecoreDockerTools powershell module is available on the local machine, if not it downloads, installs and imports it.
It generates the basic set of env variables including a base64 encoded and deflated version of the license and writes them to the .env file.
It generates certificates for traefik (again, checks for the mkcert.exe and downloads it if not available).
It adds hosts file entries with the (hard coded) hosts for the identity server and the content management server.

Improvements

We improved 3 areas:

.env file handling
License path handling
Variable support for hostname

.env File Handling

There are multiple ways of dealing with the generated .env file, but one thing that you should not do: commit the generated version of it to source control (it contains the license key after all). That's fine, as long as you're the only developer on the project. But if you're working in a team where (especially in the beginning) new environment variables are introduced all the time you have to re-create this file a lot, just to realize then, that you've (again) overridden your local customizations. That's why we have introduced to new versions of the .env file:

The .env.tpl is the template that contains initial values and is under source control
The .env.bak is a (backup) copy of the .env file to have a simple safety net if you generate a fresh .env file with init.ps1.

Essentially we've added this function to the init.ps1:

function Initialize-EnvFile() {
    $envTplFile = ".env.tpl"
    $envBackupFile = ".env.bak"
    $envFile = ".env"

    if(Test-Path $envFile) {
        Copy-Item -Force .\$envFile .\$envBackupFile
    }
    
    Copy-Item -Force .\$envTplFile .\$envFile
}

Relative Path to license.xml

By default, the script requires the user to provide an absolute path to the license.xml file. By applying the following change to the script, it can now be invoked with a relative path pointing to the license:

# Try resolving absolute or relative paths
$LicenseXmlPath = Resolve-Path -Path $LicenseXmlPath

This then allows for a simplified invocation like this:

.\init.ps1 -LicenseXmlPath ..\license.xml

Variable for the Hostname

It is a simple but effective addition if you plan to re-use the script on different projects is the new input parameter -Hostname that allows to set a specific hostname for the project. (We simply set the default value to the actual hostname.)

Full Source on GitHub

Enough chit-chat, here's the Gist with the modified init.ps1. Have look and let us know what you think!

Further Improvements

We've realized, that the most used feature of the init.ps1 script is actually the .env file re-generation (for example after branch switching). Enforcing the use of a console with administrative privileges just for this simple task seems to be a burden that we should get rid off.