Reskin Tag

How to automate the job with Node JS

You know those tedious tasks you have to do at work: Updating configuration files, copying and pasting files, updating Jira tickets.

What is a Reskin?

The definition of a reskin at the company was using the same game mechanics, screens and positioning of elements, but changing the visual aesthetics such as color and assets. So in the context of a simple game like ‘Rock Paper Scissors’, we would create a template with basic assets like below.

Pic courtesy: medium.com

But when we create a reskin of this, we would use different assets and the game would still work. If you look at games like Candy Crush or Angry Birds, you’ll find that they have many varieties of the same game. Usually Halloween, Christmas or Easter releases. From a business perspective it makes perfect sense. Now… back to our implementation. Each of our games would share the same bundled JavaScript file, and load in a JSON file that had different content and asset paths.

We had stacked daily schedules, and our first thought was, ‘a lot of this could be automated.’ Whenever we created a new game, we had to carry out these steps:

1. Do a git pull on the templates repository to make sure they were up to date.
2. Create a new branch – Identified by the Jira ticket ID from the master branch.
3. Make a copy of the template we needed to build.
4. Run gulp.
5. Update the content in a config.json file. This would involve asset paths, headings and paragraphs as well as data service requests.
6. Build locally and check content matched the stakeholder’s word document.
7. Verify with the designers they are happy with how it looks.
8. Merge to master branch and move on to the next one.
9. Update the status of the Jira ticket and leave a comment for the stakeholders involved.
10. Rinse and repeat.

Another Reskin?

Now to us, this felt more administrative than actual development work. We were exposed to Bash scripting in a previous role and jumped on it to create a few scripts to reduce the effort involved. One of the scripts updated the templates and created a new branch, the other script did a commit and merged the project to Staging and Production environments.

Setting up a project would take us three-to-ten minutes to set up manually. Maybe five to ten minutes for deployment. Depending on the complexity of the game, it could take anything from ten minutes to half a day. The scripts helped, but a lot of time was still spent on updating the content or trying to chase down missing information.

Writing code to save time was not enough. We were thinking of a better approach to our workflow so that we could utilize the scripts more. Move the content from out of the word documents, and into Jira tickets, breaking it out into the relevant custom fields. The Designers, instead of sending a link to where the assets exist on the public drive, it would be more practical to set up a content delivery network (CDN) repository with a Staging and Production URL to the assets.

Jira API

Things like this can take a while to enforce, but our process did improve over time. we did some research on the API of Jira, our project management tool, and did some requests to the Jira tickets we were working on. We were pulling back a lot of valuable data. So valuable that we made the decision to integrate it into our Bash scripts to read values from Jira tickets, to also post comments and tag stakeholders when we finished.

Bash Transition to Node

The Bash scripts were good, but if someone was working on a Windows machine, they couldn’t be run. After doing some digging, we made the decision to use JavaScript to wrap the
whole process into a bespoke build tool. we called the tool Mason, and it would change everything.

CLI

When you use Git, we assume you do in the terminal, you will notice it has a very friendly command line interface. If you misspell or type a command incorrectly, it will politely make a suggestion on what it thinks you were trying to type. A library called commander applies the same behavior, and this was one of many libraries we used.

Consider the simplified code example below. It’s bootstrapping a Command Line Interface (CLI) application.

src/mason.js

#! /usr/bin/env node

const mason = require('commander');
const { version } = require('./package.json');
const console = require('console');

// commands
const create = require('./commands/create');
const setup = require('./commands/setup');

mason
    .version(version);

mason
    .command('setup [env]')
    .description('run setup commands for all envs')
    .action(setup);

mason
    .command('create <ticketId>')
    .description('creates a new game')
    .action(create);

mason
    .command('*')
    .action(() => {
        mason.help();
    });

mason.parse(process.argv);

if (!mason.args.length) {
    mason.help();
}

With the use of npm, you can run a link from your package.json and it will create a global alias.

...
"bin": {
  "mason": "src/mason.js"
},
...

When we run npm link in the root of the project.

npm link

It will provide us with a command we can call, called mason. So whenever we call mason in our terminal, it will run that mason.js script. All tasks fall under one umbrella command called mason, and we used it to build games every day. The time we saved was… incredible.

You can see below in a hypothetical example of what we did back then, that we pass a Jira ticket number to the command as an argument. This would curl the Jira API, and fetch all the information we needed to update the game. It would then proceed to build and deploy the project. we would then post a comment and tag the stakeholder & designer to let them know it was done.

$ mason create GS-234
... calling Jira API 
... OK! got values!
... creating a new branch from master called 'GS-234'
... updating templates repository
... copying from template 'pick-from-three'
... injecting values into config JSON
... building project
... deploying game
... Perfect! Here is the live link 
http://www.fake-studio.com/game/fire-water-earth
... Posted comment 'Hey [~ben.smith], this has been released. Does the design look okay? [~jamie.lane]' on Jira.

All done with a few key strokes!

We were so happy with the whole project.

Idea Behind the concept

The first part is a collection of recipes, or instructional building blocks that behave as individual global commands. These can be used as you go about your day, and can be called at any time to speed up your workflow or for pure convenience.

Development Method

The second part is a walk-through of creating a cross-platform build tool from the ground up. Each script that achieves a certain task will be its own command, with a main umbrella command usually the name of your project encapsulating them all.

We understand that circumstances and flows are different in every business, but you should be able to find something, even if it’s small, that can make your day a little easier at the office.

For more information and to develop web application using Node JS, Hire Node Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”. To develop custom web apps using Node JS, please visit our Hire Node Developer technology page.

Content Source:

1. medium.com