Vagrant is a Ruby-based tool for building and deploying virtualized development environments. Developers love it because it allows them to easily create and deploy reproducible development environments.

With Vagrant 1.1 and the new Rackspace driver you aren’t limited to your local machine and VirtualBox anymore. You can now also run your development machines on the Rackspace Open Cloud.

This allows you to utilize all of the benefits of the Rackspace Cloud, such as instances with up to 30 GB of memory, virtual machine snapshots, server resizing and more.

For information on how to get started and more in depth look of the advantages of Vagrant 1.1 on the Rackspace Open Cloud, head over to the DevOps Blog.

There are several use cases for Service Registry. On the Rackspace DevOps Blog, I dig deeper into storing service metadata in Service Registry.

Each service object in the Service Registry has a metadata field that stores arbitrary string key and value pairs. Some of the common values you can store in this field include application version, the region and data center where the service is running, the timestamp of when a service started, JMX port for Java services and a stats port. That information can be used to display a list of services with on an internal dashboard; for client side filtering based on some metadata attribute; and for finding services which are out of date.

Head over to the DevOps Blog to read about this use case in more detail.

In upcoming posts we’ll look at more advanced use cases, including using service registry for middle-tier load balancing and using events feed as one of the information sources for your automation system.

Service Registry is currently in closed preview and is available free of charge. If you want access to the preview, you can request it by filling out this survey.

• Why we decided to build it.
• How we built it (product architecture).
• Best practices we have adopted for developing and deploying the product (continuous integration, continuous delivery / deployment, etc.)
• How we use other Rackspace Cloud products such as Cloud Servers, Cloud Load Balancers, Cloud Files and Cloud Monitoring.
• Product use cases.
• How to integrate it into your application.

In this blog post I will explain our motivation and reasoning for building it.

Why did we build Rackspace Service Registry?

While working on Cloud Monitoring we encountered several problems. One of them was that we had many different services but no easy way to keep track of them. Most services were already tracked in some way or another in Chef, but there were multiple problems with using Chef for this purpose:

• Our Chef setup is currently only deployed in a single region so it is not highly-available in the same way other components are.
• Information in Chef isn’t real-time – Chef knows if some service should be present on some server, but it doesn’t know if service is actually up and / or running.
• Chef was primarily built for applying configuration and keeping a set of servers in a consistent state that is defined in a set of cookbooks and recipes. As such, Chef primarily cares about the servers on which your application and services run. An ideal service registry shouldn’t need to know anything about the servers upon which those services run.

Cloud Monitoring is a complex product composed of multiple services running on many servers in multiple regions.

Cloud Monitoring architecture – similar set of services runs in multiple data centers

If you are interested in more details about the Cloud Monitoring architecture, please refer to the great post Paul Querna wrote last year titled Technology behind Rackspace Cloud Monitoring.

Usually the first thing we do when we need to solve a problem is look for an existing open-source project that already does what we need. In this case we could not find a project that fit our needs. We found Noah, which looked really promising, but because it’s using Redis as a main data store it didn’t fulfill our main requirement – high availability without a single point of failure. Keep in mind that this was last year, long before Netflix announced Eureka.

Because we didn’t find a project that would fit our needs, we decided to build it ourselves on top of the excellent Apache ZooKeeper project. Choosing Apache ZooKeeper had multiple advantages. We already used it for other operations such as leader election and distributed locking. This meant we were already familiar with its APIs and operations, so using it added no complexity or mental overhead to our project.

The data model and distributed architecture of Apache ZooKeeper make it a good fit for building a service registry on top of it.

The service registry we built in Cloud Monitoring is simple, but it makes service discovery and some other things a lot easier. Here are some examples:

• Service discovery – e.g. finding all the API servers located in ORD
• Jobs discovery – We registered all the long running jobs (e.g. a script that calculates daily usage statistics, etc.) in the registry and this allowed us to see which jobs are currently running.
• Version check – When registering an API server in the registry we included current version in the payload field. This allowed us to easily check which version of the software is running on which servers and check for potential version mismatches.

We quickly saw that the service registry added a lot of value and simplified operations.  This motivated us to start thinking about how we could share it with other internal and possibly external users.

One approach would be to run a separate ZooKeeper cluster and service registry for each user/tenant, but this would be expensive to operate and maintain. Because of that we decided to build a new service registry using a SaaS model designed with multi-tenancy in mind from the start.

The new Rackspace Service Registry service builds on the core ideas and use cases we observed in Cloud Monitoring. While the original Cloud Monitoring service registry was simple and only offered service discovery, the new registry goes beyond that by offering useful features we think are helpful when building highly available and scalable applications. Some of these new features are listed below.

Better object model

In the Cloud Monitoring service registry we only had one object called service that could contain arbitrary key/value pairs in the payload field. This worked fine for our very simple and focused use case.

In Rackspace Service Registry we expanded this model and introduced a concept of a session and added “tags” and “metadata” fields to the service model. This allows users to use service registry in a variety of ways that were not possible with the previous model. You can learn about some of those ways in the next blog post where I will talk about some common use cases.

HTTP + JSON

In the Cloud Monitoring service registry, clients talked to the registry over TCP using a native binary ZooKeeper protocol.

In the Rackspace Service Registry we went with HTTP and JSON. In cases like this, a combination of HTTP + JSON has multiple advantages:

• It’s easier to start playing with it – you can use simple command line tools such as cURL.
• It’s easier to build clients and talk to the service because almost every programming language supports HTTP.
• It’s easier to debug issues because the text is human readable.

In Rackspace Service Registry HTTP is also used for letting us know that the session is alive. This is done by heartbeating the session – periodically sending an HTTP POST request. Some people would argue that sending many heartbeats over HTTP is expensive, but we believe that with using HTTP/1.1 persistent connections this is not an issue.

Events Feed

We added an events feed that includes all of the events that have happened during the lifecycle of your account (e.g. a service comes online, a configuration value gets updated, etc.).

The events feed is a great information source about your infrastructure and can act as a platform for auto-scaling or be used to kick off a host of different automation processes.

Configuration Storage

Configuration storage allows users to store arbitrary configuration values in our system and get notified via the events feed when a value gets updated or deleted.

Storing all the configuration values in a centralized place allows for better visibility and easier introspection of the configuration data. It also allows applications to react to changes faster and makes automation of tasks that rely on those values a lot easier.

In a typical application you usually have configuration values stored in a config file and if you want to update it you kick off some process that updates the configuration file and restarts the service or sends it a SIGHUP signal.

With the Service Registry Configuration Storage feature you can poll the events feed for changes inside your application and once the value changes you can more easily and quickly react to those changes directly in your application.

Conclusion

I hope you’ve found this post helpful! If you haven’t signed up for the preview yet, I encourage you to do so by filling out this short survey. I also encourage you to come back next week when I’ll talk more in depth about why you might need Service Registry and present some typical use cases.

Rackspace Service Registry is one of the first Rackspace services focused on helping our customers run and automate their application versus their infrastructure.

Rackspace Service Registry Overview

What is Rackspace Service Registry?
Rackspace Service Registry is an API-driven cloud service built to keep track of your services and store configuration values, which allows you to react to changes faster and make your application or service more highly-available.

The functionality that it exposes includes:

Service Discovery
Find which services are currently online/active and find services based on different criteria. You can organize your services however best fits your application deployment.

Platform for Automation
Service Registry exposes an events feed, which includes all of the events that have happened during the life-cycle of your account (e.g. a service comes online, a configuration value gets updated, etc.).

Events feed is a great information source about your infrastructure and can act as a platform for auto-scaling or be used to kick off a host of different automation processes, including:

• Add a web service to a load-balancer when it comes online
• Open a ticket in the internal ticketing system when a services goes offline
• Re-initialize the connection pool inside your application when a configuration value changes

Configuration Storage
Configuration storage allows users to store arbitrary configuration values in our system and get notified via the events feed when a value gets updated or deleted.

Check out API Guide, Integration Guide, Client libraries and tools and Release Notes for more details.

Why did we build it?
Our primary motivation for building Service Registry was our need for it internally. We had already developed and used an internal project that offered a small subset of the features available in Service Registry, but it was difficult to maintain and scale.

When we started building the new product, we looked at what our current solution already offered and what we and our customers needed. The result is a Service Registry built on top of Apache Cassandra and Apache ZooKeeper that offers a lot of the functionality required for building highly-available services in dynamic environments.

We are releasing it as a cloud service because we want the general public to enjoy the same benefits we experience.

How does it work?
Rackspace Service Registry exposes a REST based API, which means you communicate with it using HTTP(s).

The main concept in the Service Registry is a so called heartbeat. A heartbeat lets our system know that your service is alive and healthy. When a session is initially created, you must specify a heartbeat interval that defines how often you need to heartbeat the session.

If you don’t heartbeat a session in the defined interval, the session is considered dead, and a new event is inserted in the events feed that indicates the session and all of the services associated with it have died.

For more information about the terminology and concepts please refer to the API documentation.

How do I integrate my services with it?
There are several options to integrate your services with Rackspace Service Registry:

1.  Download one of the official client libraries (currently we have libraries for Node.js, Twisted Python and Java) and include it in your service code.

If there is no client library for your programming language of choice and you want to build one yourself, be sure to check Best Practices for Writing Client Libraries chapter in the documentation.

2. Use the “long-running process wrapper” tool which allows you to register arbitrary long-running processes with the Rackspace Service Registry.

Method No. 1 requires a bit more work on your side, but it offers more fine-grained level of control and it is the preferred method.

How does it compare to Chef/Puppet/other configuration management solutions?
Rackspace Service Registry is not meant to replace configuration management systems like Chef or Puppet, but it can be used to augment their functionality.

In a lot of scenarios people store different configuration values in Chef inside attributes and data bags, and when performing a Chef run, configuration values get written out to a file on disk, and usually a service needs to be restarted or SIGHUP-ed to read those changes.

Service Registry allows users to store arbitrary configuration values on the server and be notified when a value changes or is deleted. This allows users to move this functionality into code and react to changes faster without interruption to the service.

A good use case for this is storing a list of database server IP addresses inside the configuration value in the Service Registry. Inside the code, users can poll the events feed for changes and re-initialize an internal connection pool when a value changes. This allows users to react to those changes faster compared to using other solutions such as using DNS hostnames instead of IP addresses.

How is it different from Netflix’s Eureka?
Rackspace Service Registry is different from Netflix’s Eureka in multiple ways:

1.  It’s a hosted service
No Installation and Maintenance: Our service is a hosted service, which means we run it and operate it. This removes the load from your operations staff and allows you to put more resources into more business critical components of you application.

Zero Downtime Update: Besides removing the operational load, the software as a service model allows you to benefit from continuous zero downtime updates, which are performed by our team almost every day.

2. It’s backed by Rackspace Fanatical Support
Like all of our services, Service Registry is backed by our trademark Fanatical Support. If you have a problem or need help, you can always call us and we will happily assist you.

3. It has a Configuration Storage feature
Besides the Service Registry, our service offers a Configuration Storage feature, which allows you to store arbitrary configuration values in our service and be notified via the event feed when they are updated or deleted.

4. It offers official client libraries for more programming languages
Netflix’s Eureka only has a single official client library written with Java. Starting with this preview, we offer official client libraries for the following programming languages:

• Java
• Node.js
• Twisted Python
• Python

Because we want to keep the user experience great, our goal is to also create and support official client libraries for other popular programming languages such as Ruby.

Where can I apply for the preview?
To apply for the beta program, please fill out this short survey with your contact information and use case and we will determine your eligibility within 48 hours.

We look forward to hearing from you and getting valuable feedback, which will allow us to make product even better.

Between 0.6.1 and current release (0.10.1) seven months of development took place and a lot of new features and improvements were added, which I want to talk about in this blog post.

Improvements In The OpenStack And Rackspace Drivers

OpenStack and Rackspace drivers received a lot of improvements and new features, including, but not limited to:

• Keystone 2.0 support (authentication),
• New storage driver which works with OpenStack Swift installations
• Large object upload support for CloudFiles driver
• A lot of improvements and new extension methods in the Rackspace load balancer driver

Python 3 Support

The 0.7.0 release introduced full support for Python 3. Libcloud is now one of the first Python cloud libraries that supports Python 2.5, Python 2.6, Python 2.7 / PyPy and Python 3 with a single code base.

Support For Compressed Responses

Since the 0.8.0 release Libcloud now knows how decompress and handle compressed responses (deflate, gzip). Compressed responses are usually much smaller than the uncompressed ones, which means this will save you a decent amount of bandwidth, especially if you do a lot of polling.

New Drivers

Since the latest update Libcloud has added support for more than 10 new providers and locations:

• CloudStack (compute)
• OpenNebula v1.4, v2.x and v3.x (compute)
• Joyent (compute)
• VCL cloud (compute)
• Vmware vCloud v1.5 (compute)
• IBM SCE (compute)
• libvirt (compute, experimental)
• Amazon EC2 South America and Oregon locations (compute, storage)
• ElasticHosts United States and Canada locations (compute)
• CloudSigma United States location (compute)

Conclusion

This is just a short list of new features and improvements that have landed in trunk in the last seven months. For a full list of changes, please see the CHANGES file. You can find more information including examples and a getting started guide, and follow Libcloud development and news on the project website – http://libcloud.apache.org/.

An important building block of RESTful APIs is a system for serializing/deserializing responses and validating incoming data. Many other frameworks already have a library available (e.g. django-piston for Python / Django), but when we started to work with Node.js there was no such library so we decided to build our own library called node-swiz.

Node-swiz is very powerful and flexible and can be used as a building block for very simple or complex RESTful APIs. The library itself introduces four main concepts which are described below with examples.

Swiz definitions

A Swiz definition describes how an object is serialized, deserialized and validated.

Here is an example object definition for a Server object:

Swiz struct module exposes two factory methods  – Obj for an object and Field for a field.

Each object takes the following arguments:

1. Name – in our example is Server
2. An object with the following properties:
a. fields – an array of Field objects (more details below)
b. singular – singular name for this object (defaults to the object name if not provided) used when serializing lists in XML documents
c. plural – plural name for this object used when serializing lists in XML documents

Each field has a name (first argument which is passed to the factory method) and takes an object with many options as a second argument:

• src – name of the key on the object which is used as a source for the actual value. If not provided it defaults to the field name. This can also be name of a method on the object which is called when serializing it. This method gets passed in a callback and must pass a value as a second argument to this callback. You can find an example of how to do that in the Serialization section below.
• desc – field description.
• attribute – if true value will be included as an attribute instead of a tag when serializing to XML.
• coerceTo – type to coerce the value to when deserializing a payload. This is only applicable when deserializing XML.
• singular – name of a container tag when serializing a list to XML.
• plural  – name of an item tag which is wrapped inside a container tag when serializing a list to XML.
• enumerated – a list of enumerations for this value.
• filterFrom – a list of targets from which this field should be excluded when serializing an object. User can pass in a target to the Swiz constructor in the options object. Below is an example which shows how to accomplish that in the Serialization section.

Serialization

Serializing an object is easy and can be done in 2 steps:

1. Instantiate a Swiz object with a list of your definitions
2. Call a serialize method on the instantiated object and pass in requested format (JSON or XML) and your object

Here is an example which shows how to do that:

JSON output:

JSON output (serializing for target called public):

In this case public_ips attribute is not included in the serialized object, because the definition contains filterFrom option and we are serializing for target called public.

XML output:

As you can see, our Server class has getSerializerType method. This is a special method which must be present if you want to serialize an object and tells Swiz which definition to use when serializing it.

Deserialization

Deserializing in Swiz means taking a JSON or XML payload and deserializing it to a JavaScript object. This can be done using a deserializemethod on the swiz object. Here is an example which shows how to de-serialize a Node XML document:

And the output:

Deserializing a JSON document is the same, but instead of passing swiz.SERIALIZATION.SERIALIZATION_XML to the deserialize method you pass in swiz.SERIALIZATION.SERIALIZATION_JSON.

Validation (Valve)

Imagine how cool would it be if you could use the same definitions you already use for serializing and deserializing objects to also validate user data. That’s exactly what you can do with Swiz’s component called Valve. Valve is a Swiz component for validating data and making sure it conforms to the rules defined in the object definition.

Example which shows how to validate an object:

And the output:

If the validation succeeds, Swiz passes a cleaned object to the callback as a second argument. In the first example you can also see how toBoolean() transformation function works. We passed in 1 for the active key value, but Valve casted it to a boolean.

As you can see in the second example, if the validation fails, Swiz passes back a special error object to the callback as a first argument. This object contains a detailed error message and the key which failed the validation.

How we use node-swiz in Cloud Monitoring

In Cloud Monitoring we use Swiz extensively inside the API server to deserialize and validate all the incoming data for a particular request. However, another interesting point is we use swiz and valve on a non-HTTP protocol, but over a plain TLS TCP socket. Inside our upcoming agent endpoint we use swiz/valve to validate payload of the JSON-RPC messages sent by the agent.

Serialization and deserialization
Our API supports both JSON and XML formats and we use Swiz to deserialize all the request payloads and serialize all the responses. For serializing and deserializing XML within Swiz, it uses the previously described node-elementreelibrary.

Validation
After the API request comes in and it’s parsed by Swiz we use Valve to validate the payload and make sure it conforms to all the rules specified in the definitions. If the validation fails we return a detailed error back to the user.

Automatic documentation generation
Another place where we use Swiz is for generating parts of our documentation. Every time we push to master our buildbot automatically starts a build which, among other things, generates parts of the documentation using Swiz which are then included in the main documentation file. Keeping documentation in sync with code is important but usually an overlooked thing. Using Swiz to generate parts of the documentation allows us to automate this process and makes sure that our documentation is always accurate and up to date.

Entities attributes table is automatically generated using Swiz definitions

Check type details field table is automatically generated using Swiz definitions

Conclusion

I hope you found this post helpful! Don’t forget to play with the library and check out the code on Github – https://github.com/racker/node-swiz. We will see you around soon when we talk about another Node.js library we have open-sourced.

If you think this kind of work would be challenging and fun, and you enjoy contributing to open-source projects, we are always looking for talented engineers.

We began collecting requirements before we started to build our Monitoring-as-a-Service (MaaS) platform and one of the requirements was to support XML. None of the developers in our team particularly like XML (we prefer JSON), but we needed to support XML because some of the API consumers still use it. When we started working on the project, there wasn’t a good library available for creating XML documents, so we decided to build our own. Many of the developers on our team have previously worked with Python and were familiar with Python’s ElementTree API, so we modeled our library after ElementTree’s straightforward and easy to use interface.

In this blog post I am going to go over a couple examples of leveraging the API.  First we’ll start with creating a document, and then we’ll talk about parsing a document.

Example 1 – Creating An XML Document

This example shows how to build a valid XML document that can be published to Atom Hopper. Atom Hopper is used internally as a bridge from products all the way to collecting revenue, called “Usage.”  MaaS and other products send similar events to it every time user performs an action on a resource (e.g. creates, updates or deletes). Below is an example of leveraging the API to create a new XML document.

var et = require('elementtree');
var XML = et.XML;
var ElementTree = et.ElementTree;
var element = et.Element;
var subElement = et.SubElement;

var date, root, tenantId, serviceName, eventType, usageId, dataCenter, region, checks, resourceId, category, startTime, resourceName, etree, xml;

date = new Date();

root = element('entry');
root.set('xmlns', 'http://www.w3.org/2005/Atom');

tenantId = subElement(root, 'TenantId');
tenantId.text = '12345';

serviceName = subElement(root, 'ServiceName');
serviceName.text = 'MaaS';

resourceId = subElement(root, 'ResourceID');
resourceId.text = 'enAAAA';

usageId = subElement(root, 'UsageID');
usageId.text = '550e8400-e29b-41d4-a716-446655440000';

eventType = subElement(root, 'EventType');
eventType.text = 'create';

category = subElement(root, 'category');
category.set('term', 'monitoring.entity.create');

dataCenter = subElement(root, 'DataCenter');
dataCenter.text = 'global';

region = subElement(root, 'Region');
region.text = 'global';

startTime = subElement(root, 'StartTime');
startTime.text = date;

resourceName = subElement(root, 'ResourceName');
resourceName.text = 'entity';

etree = new ElementTree(root);
xml = etree.write({'xml_declaration': false});
console.log(xml);

https://gist.github.com/2554363

As you can see, both et.Element and et.SubElement are factory methods which return a new instance of Element and SubElement class, respectively. When you create a new element (tag) you can use set method to set an attribute. To set the tag value, assign a value to the .text attribute.

This example would output a document that looks like this:

<entry xmlns="http://www.w3.org/2005/Atom">
  <TenantId>12345</TenantId>
  <ServiceName>MaaS</ServiceName>
  <ResourceID>enAAAA</ResourceID>
  <UsageID>550e8400-e29b-41d4-a716-446655440000</UsageID>
  <EventType>create</EventType>
  <category term="monitoring.entity.create"/>
  <DataCenter>global</DataCenter>
  <Region>global</Region>
  <StartTime>Sun Apr 29 2012 16:37:32 GMT-0700 (PDT)</StartTime>
  <ResourceName>entity</ResourceName>
</entry>

https://gist.github.com/2632179

Example 2 – Parsing An XML Document

This example shows how to parse an XML document and use simple XPath selectors. For demonstration purposes, we will use the XML document located at https://gist.github.com/2554343.

Behind the scenes, node-elementtree uses Isaac’s sax library for parsing XML, but the library has a concept of “parsers,” which means it’s pretty simple to add support for a different parser.

var fs = require('fs');

var et = require('elementtree');

var XML = et.XML;
var ElementTree = et.ElementTree;
var element = et.Element;
var subElement = et.SubElement;

var data, etree;

data = fs.readFileSync('document.xml').toString();
etree = et.parse(data);

console.log(etree.findall('./entry/TenantId').length); // 2
console.log(etree.findtext('./entry/ServiceName')); // MaaS
console.log(etree.findall('./entry/category')[0].get('term')); // monitoring.entity.create
console.log(etree.findall('*/category/[@term="monitoring.entity.update"]').length); // 1

https://gist.github.com/2554353

Basically, the module exposes three methods on the ElementTree instance:
•    etree.find – return a single element which matches the XPath selector
•    etree.findall – returns an array of elements which match the XPath selector
•    etree.findtext – return a text value of the tag which matches the XPath selector

For more information on how to use XPath selectors you can refer to the Python documentation.

How We Use node-elementtree In MaaS

In MaaS we use it in two places:
1. Sending usage documents to an Atom Hopper instance
2. Returning a response to the API user which has requested a response format to be XML

In the second case we actually use it in combination with our validation and serialization framework called Swiz. We use Swiz to define field types and validators for every object in the system. When a user hits our API and requests XML, Swiz serializes the response using the object definition and node-elementtree library.

Conclusion

I hope you found this post helpful! More examples and project source code can be found on Github. We will see you around soon when we talk more about our previously mentioned serialization and validation framework called Swiz. If you think this kind of work would be challenging and fun, and you enjoy contributing to open-source projects, we are always looking for talented engineers.

For us (and many others), open source is an enabler to building new products (just like the cloud) and we’re part of strong communities and other projects. However, when we get a chance to open source something, we jump at the opportunity to give back.  And to be honest, we get back something in return.  Peer review, feedback and general discussion around the technologies help us make them better.

We’ve invested a lot of time and effort in Node.js and it has enabled so much velocity in such a familiar paradigm.  We have a ton of modules to share with the community.  The first one we’d like to share is around testing and test automation.  So to kick it off, our first piece of technology is the Whiskey test automation stack named after our team’s favorite adult beverage.

When we first started working with Node.js there weren’t many different test frameworks available. There was expresso and some other BDD frameworks and that was pretty much it. Since we didn’t really follow the BDD practices we decided to go with expresso.

It worked fine for basic async and unit tests, but it didn’t really offer any kind of test isolation and process orchestration which we were looking for. Those are just two of the reasons we decided to write our own test framework called Whiskey.

Test Isolation

In Whiskey test isolation is achieved by running each test file (a test file is a collection of tests) in a separate child process. This model is also more scalable compared to a classical model where all the tests run in the same process. Currently child (worker) processes communicate with a parent (reporter) process over a Unix socket, but in the future we could easily change this to TCP and distribute child (worker) processes over multiple servers.

Process Orchestration

In our product we have a lot of integration tests and services that tests depend on. Those services also have a lot of inner-dependencies, e.g. Zookeeper and Cassandra need to be started before the messenger service and so on. At first, when we only had a few services, we used a custom SCons target that started all the services before running the integration tests. Maintaining custom SCons targets soon became too cumbersome and simply starting all the services one by one in a sequential order was relatively slow. That’s why we added support for process orchestration to Whiskey.

Process runner uses a simple JSON configuration file where you specify all the services and their dependencies. When you start Whiskey with –dependencies <config path> option, the config file is parsed and used to start services in the correct order. If it is possible, multiple independent services are also started in parallel, which speeds up the whole bootstrap process.

If you are interested in more details you can also read a post I wrote on my personal blog called Whiskey Node.js test runner now with more goodness – introducing process runner.

Process runner starting the processes before running our integration tests.

Test Coverage

One of the important features on our list was also a fully integrated code coverage framework. Expresso did offer basic code coverage support, but it only supported outputting the results to the console, which is not useful for larger files and projects. The code coverage module in Whiskey is similar to expresso using node-jscoverage for actually instrumenting the code, but it offers more flexibility and features, including:

●    three different reporters – text, html and json
●    support for hooking up the coverage for services started with the process runner
●    support for aggregating code coverage reports

Aggregated code coverage reports are especially useful if you have multiple test suites in a single code base. In our case we have two types of tests – simple unit tests which don’t rely on external services and more complex integration tests which rely on different services. We use the JSON reporter when we are generating code coverage reports. This way, Whiskey writes out a JSON file with the code coverage statistics before exiting. In our case we end up with multiple different JSON coverage report files: one for simple tests, one for integration tests and one for each node service that has been started by the process runner. The report files are aggregated with a –coverage-aggregate option and we end up with a nice looking HTML report.

Code coverage HTML report overview page.

Code coverage HTML report single file view.

Those are just a few of the cool features of Whiskey. Other features include:

●    support for async tests
●    support for tap output
●    support for reporting variables which have leaked into the global scope
●    support for generating Makefiles with common test targets
●    simple integration with node debugger
●    support for reporting tests timing

That’s it for today. Don’t forget to check the Whiskey github page and check back for a future post when Racker Gary will talk about the Node.js Cassandra CQL client we have open sourced.

As much as we love building these technologies, we’d love for people to use and break them. All of these projects are released under the Apache 2.0 license and available under the github.com/racker organization. Would you like to work on project like this? Check us out, we’re hiring.