Deployment Tracker Screenshot
A screenshot of the Deployment Tracker service taken in October of 2015 (deployments-by-month numbers redacted).

I recently wrote about my experience as a Developer Advocate here at IBM Cloud Data Services. One of the things that we do as Developer Advocates is create sample apps that demonstrate various aspects of our offerings (like our Location Tracker sample app which demonstrates how to track and map location with HTML5, JavaScript, and Cloudant). However, we had no way to measure whether or not anyone was actually using these sample apps. Sure, we could look at GitHub watches, stars, and forks, but this wouldn’t tell us if people were actually deploying the apps.

To address this problem we worked closely with the IBM Bluemix Developer Advocacy team to build a Deployment Tracker service along with a Deployment Tracker Node.js client library and a Deployment Tracker Java client library. The Deployment Tracker now lets us see when someone deploys one of our sample apps to IBM Bluemix.

How it Works

Whenever we create a sample app, we now include the Deployment Tracker client library in the sample app and add a line (or a few lines, depending on how deployment tracking is integrated into the application) that triggers the deployment tracking. This in turn pings the Deployment Tracker service with some metadata about the deployment, such as the app’s name (application_name), space ID (space_id), version (application_version), and its URIs (application_uris). This metadata is collected from the VCAP_APPLICATION environment variable found in IBM Bluemix and other Cloud Foundry platforms.

Using Our Own Services

We built the Deployment Tracker using our own tools and following the processes for which we advocate. The Deployment Tracker service is built using Node.js, runs on IBM Bluemix, and uses IBM Cloudant as its data layer. Our plan is to keep the Deployment Tracker as a microservice which focuses on doing one job: tracking deployments. We have plans for additional microservices that will collect additional metrics that are valuable to our team.

Development of the Deployment Tracker has been agile and iterative (the initial iteration of the Deployment Tracker was developed in three days). All of our work is done in public GitHub repositories. For the Deployment Tracker service we require every team member (even core contributors) to send pull requests and require a review by at least one other team member before merging. We use the Cloud Foundry blue/green deployment module from 18F and Travis CI for zero-downtime, continuous deployments.

Working in the Open

Bluemix Deployments
A badge displaying the number of times that the Hello World Node.js sample app has been deployed to Bluemix.
Deploy to Bluemix
A Deploy to Bluemix button displaying the number of times that the Hello World Node.js sample app has been deployed to Bluemix.

One of our core tenants at IBM Cloud Data Services is that “we will work in the open.” To this end we recently added deployment badges and buttons to the Deployment Tracker. These badges and buttons can be embedded in a project’s README or on related tutorials and blog posts. The Deployment Tracker badges and buttons let anyone see how many times the sample app was deployed. For now we just provide a count of deployments. In the future we may provide more detail such as deployments over time.

Privacy

Collecting information about deployments helps us improve on the sample apps and other material that we create for you. READMEs state clearly when a sample app uses Deployment Tracker, and we provide a privacy notice and instructions on how to disable deployment tracking too. Disabling deployment tracking is quick and easy for those who are not comfortable having their deployments tracked.

Join The Discussion

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