Creating custom deployment tools using Grunt

For ThoughtFarmer, we needed a way to build, package and deploy Custom cards to our API endpoints. This would allow us, and our clients to develop customizations right from their own local IDEs and deploy to whichever environment was required. The previous model used the web based code editors that are available in the ThoughtFarmer Administration panel. Web based editors do no offer anything close to the flexibility and ease of use of their desktop counterparts, and the only other option was a tedious copy\paste\update workflow…yuck.

The catch here is that each custom card would have a specific ID that may vary depending on which site it was being deployed to. This meant that whatever tool we used would need to be flexible enough to allow for command line parameters to configure the build\deploy workflow. We also needed a clean way to supply some auto-parameters and configuration. Then you could make the most widely used calls easily and set and forget the others.

Grunt seemed like the logical choice for this. We were already using it internally for our React transpilations from JSX to pure JavaScript. It was also used to build and package all of our other client side code. However, we were not doing anything more complex command line wise then grunt dev or grunt legacy. So I needed to find out if Grunt could even accomplish the task required. Fortunately, with the vast eco-system of packages available, my search was not long.

 

The secret sauce

The magic recipe was a collection of Grunt packages that provided exactly what we needed. Those packages are:

  • Babel: For transpilation of our React JSX files into cross browser friendly JavaScript. We use the es2015 preset as we need to tow IE along for the ride.
  • ESLint: For linting of our JavaScript and JSX. Although, we do not typically lint any transpiled JavaScript.
  • grunt-http: So we could send all of our packages to the ThoughtFarmer API endpoints that would accept them.
  • grunt-prompt: A great command line UI for creating interactive prompts. This was really the package that brought this all together. It facilitated all of the interactive prompts with great ease so configuration and deployment parameters could be collect right from the command line.
  • grunt.util.spawn: This is not a package, but a core function of the grunt utility. This little beauty allowed the ability to pass up parameters from child folders to the parent process. Without it command line parameter repetition would have been extremely annoying.

In the next upcoming blog posts I will go over the various components of this tool and how they all work together.

Leave a Reply

Your email address will not be published. Required fields are marked *