Helix Deployments without Gulp

The Challenge

For some time now, I’ve wanted to eliminate Gulp from the build and deploy workflow of Helix based solutions. The issues I’ve had with using Gulp are:

  1. Developers and DevOps must know Gulp to troubleshoot or enhance functionality.
  2. Software must be installed and configured in addition to Visual Studio and scripting technologies, which come installed with Windows.
  3. A considerable amount of NPM modules must be downloaded merely to execute the gulpfile.
  4. Executing the gulpfile results in unproductively long runtimes.
  5. Failures due to file locking increase in frequency as the number of modules increase in the solution.

Asides from the issues noted above, the use of Node, NPM, and Gulp has never set well with me. Surely there has to be a way to achieve the same results with more Visual Studio native technologies.

The Solution

After having a very informative conversation with one of our DevOps, Dennis Weston, it became embarrassingly obvious that MSBuild is, at minimum, all that’s necessary to deploy locally. The irony is the answer was staring me in the face the whole time since the Gulp approach also used MSBuild.  By pairing MSBuild with PowerShell scripting, we can achieve the same functionality as the Gulp approach, but with native Microsoft stack technologies.

So, how does a PowerShell and MSBuild approach address the issues I listed above with a Gulp approach?

  1. Instead of required knowledge of Gulp, PowerShell is the required technology to know. I’m guessing it’s more likely a developers and/or dev ops personnel would have knowledge of PowerShell before Gulp.
  2. There is no additional software that needs to be installed. PowerShell has shipped with Windows since Windows 7 and MSBuild is part of the .NET Framework install and the Visual Studio install.
  3. Unless your PowerShell script requires custom cmdlets, there is nothing to download.
  4. Execution of MSBuild as a stand-alone command is extremely fast in comparison. Even included in a PowerShell script, the runtime is fast.
  5. File lock is not an issue when calling MSBuild directly or from within a PowerShell script.

The MSBuild command that needs to be executed publish locally is as follows:
MSBuild {solution file} /p:DeployOnBuild=true /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:Configuration=local /p:publishUrl={website folder path}

Instead of making a stand-alone MSBuild call as shown above, I prefer to call it from within a PowerShell script. This allows me to execute pre-publish hygiene logic. For example, before each publish, all config files under the project, feature, and foundation folders can be deleted. Likewise, Razor Views under each of the corresponding module projects can be deleted to ensure there are no lingering files.

On the CI server, a PowerShell script will be necessary to prep Unicorn serialization files for deployment, assuming your solution uses Unicorn as well. Any functionality from the Gulp counterpart will have to be converted into a PowerShell script(s).

I hope this post gives you some ideas of how to move off Gulp as the publishing mechanism for your Helix based solution.

Categories: Habitat, Helix, Sitecore