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 email@example.com:your_user_name/badge-ribbons-stars.git 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:
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 README.md file. After I add the build image hook, my README.md file looks like this:
badge-ribbons-stars [![Build Status](https://travis-ci.org/Adron/badge-ribbons-stars.png)](https://travis-ci.org/Adron/badge-ribbons-stars)
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 README.md 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 README.md 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 http://badgesribbonsstars.azurewebsites.net/ 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
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.