The Work and Flow of JavaScript Development: Continuous Delivery

In April, I wrote about The Work and Flow of JavaScript Development: Getting Started, detailing the steps I go though to set up a work situation and the flow I use to complete the work. This time, I’ll discuss how to get the project ready for multiple people and myself to code against, and implement continuous deployment practices that will give the team feedback in real time. Even if I’m the only one coding through the work and flow, I like to ensure that I can have anybody join in to the effort at any time.

Project Repository

The first step toward getting a project ready for a team to work on is to set up a public repository for everyone to work against. In an enterprise setting, this might be something like Subversion, git, or another source-control solution. For this example, let’s go with a git repository on Github.


I have chosen to make this repository public, so anybody can clone it and use it for their own site. Below that, I’m initializing the repository with a README file, setting it up based on a Node code base, and giving it an Apache v2 License.

Before committing the code base I created in the initial article to the new public repository, I need to make a quick change. I’ll add an entry to the .gitignore file to leave the WebStorm IDE settings directory where they are so they don’t get committed to the code base. In the screenshot below, a red arrow points to where I’m adding the “# WebStorm” comment and the “.idea” entry to ignore that directory.


From here on, the steps are pretty easy. Next, I’ll clone the project that has the initialized files from Github to a local path:

git clone to_some_directory

Then, I’ll copy the project contents over the cloned project, add the project files committed, and push the content:

git add -A
git commit -m ‘Added express.js app project content.’
git push origin master

Once everything is pushed to the repository, I like to check it out on Github to make sure everything is available. There’s no real need to do this, as the command confirms the result, but I like to see the files on the Github site repository page as a mental checklist.


Now that I have this in a repository, I want to have a clean process to get a build and deploy it to a nice test environment. For this I’m going to use Travis Continuous Integration and Windows Azure.

The Continuous Delivery Build

First I add a .travis.yml file to the project root with the following content:

language: node_js
- 0.10

This file provides the configuration for the Travis CI service, telling it to launch a build with Node.js version v0.10.x as the build runner.

Next I’ll add a build image hook to the file. After I add the build image hook, my file looks like this:

badge-ribbons-stars [![Build Status](](

The badge, ribbons and stars report site.
Badge, Ribbons & Stars Report Web Application!

Now I navigate over to my Travis CI Account page to turn on the repository to receive pull and push requests.


In the repository list, I click the button to turn on the repository to get the next commit queued into the build.


After that, a simple git push with the latest changes kicks off my build.

git push origin master

With results that look something like this:


At this point, anyone working on the project can check to see if the latest build is good by viewing the on Github to see if the build image is displaying a passing build.


The Continuous Delivery Deployment

Now for the final stage of deploying the app to a staging environment. For this I’m going to set up a staging environment in Windows Azure. It’s one of the simplest environments in which to run Node.js apps. This step assumes you already have a Windows Azure account.

First, pull open the Windows Azure management console and click on the giant +NEW button.


Then navigate through the dialog by clicking on Compute -> Web Site -> Quick Create, and then fill out the URL, web hosting plan, and region fields. Click the Quick Create button to initiate the server launch.


Once the application has created itself, click on it to go to the next step.


On the right side of the next screen there’s a menu option to “Set up deployment from source control.” I click on that to bring up a dialog to set the Github account and pull down a list of repositories.


Following these steps, I choose Github from the dialog, authenticate it, and select the repository. That starts a build in Windows Azure, which goes live once it’s complete.


Finally, navigating over to the site reveals that, sure enough, there’s my solid build showing that my Express.js app has indeed been deployed from Github.

Summary and what’s next

My initial post on The Work and Flow of JavaScript Development is a short and simple user story: “The end user wants to be able to list the geek badges they’ve attained through hackathons, contributions on github, and other places.”

In this post, I’ve stepped through the work of preparing for a smooth flow of development. I’ve covered the basics of starting a public repository on Github. After that I dove into an example of a continuous integration build set up on Travis CI and automated deployment from Github to Windows Azure.

Stay tuned: For the next part of this process, I plan to dive into some code around building out test data to work with, the respective models for that test data, and more, based on the user story introduced in the original post.'

Adron Hall is a jovial, proactive, test & code, code & test, get things done well, software architect, engineer, code monkey, coder, and distributed systems advocate. As a coder, Hall plies a polygot language path including C#, Java, JavaScript, and Erlang lately -- as well as Pascal, Basic, Visual Basic, C++, C, COBOL, RPG, CL, and others in the past. He founded with Aaron Gray, Node PDX with Troy Howard, and more startups are in the works. You can read his blog at Composite Code ( View posts by .

Interested in writing for New Relic Blog? Send us a pitch!