Git Push Heroku Master: Now 40% Faster

Flow is an important part of software development. The ability to achieve flow during daily work makes software development a uniquely enjoyable profession. Interruptions in your code/test loop make this state harder to achieve. Whether you are running unit tests locally, launching a local webserver, or deploying to Heroku there's always some waiting and some interruption. Every second saved helps you stay in your flow.

We’ve been working on reducing the time it takes to build your code on Heroku. Read through this post for details on the process we used to make builds fast, or check out the end result from the graph below:

heroku_build_speed@2x

Let's take a look at our process in delivering these improvements further.

Read more →

Heroku XL: Focusing on Large Scale Apps

Having a web or mobile app become hugely popular is one of those "good problems" to have. But success is still its own challenge - making any architecture work at high volume can often create a unique kind of complexity. And as the Internet grows, and apps become more prevalent, its an increasingly common requirement.

The largest app on Heroku routinely exceeds 10,000 requests / second, and two of the top 50 sites on the Internet (as measured by Quantcast) - Urban Dictionary (45th largest) and Upworthy (40th largest) - run on Heroku. Across all apps, Heroku is now serving over 5 billion requests per day (or about 60,000 requests per second).

Heroku has always been guided by the goal of making it as easy as possible to build and scale apps in the cloud, and we want to extend those same benefits to the largest "XL" app developers. Working with these and other customers, we’ve seen a consistent pattern of requirements from high scale apps, which we are announcing today as a set of features and services to help make the pattern of XL apps simpler and more easily repeatable.

Read more →

Auto-generating a Go API client for Heroku

Editor's note: This is a cross post from Blake Gentry, an engineer at Heroku.

This is a post about the recently announced Heroku Platform API JSON Schema and how I used that schema to write an auto-generated Go client for the API.

Heroku's API team has spent a large part of the past year designing a new version of the platform API. While this is the 3rd incarnation of the API, neither of the two previous versions were publicly documented. In fact, the only documentation on the old APIs that was ever published is the source code of the Heroku Rubygem, which powers the Heroku Toolbelt. That worked fairly well at the time for Heroku's Ruby-centric audience, but it was never ideal, especially since Heroku's developer audience now uses many languages besides Ruby.

Additionally, the first two "versions" of Heroku's API were developed organically as the platform's capabilities evolved, with contributions made by many engineers over the years. The API was built primarily as an interface for the toolbelt, rather than as a product. It was also not properly versioned, as there was no process for managing changes publicly. And because the API was not treated as a product in and of itself, the old APIs are scarred by numerous inconsistencies and lack coherence.

Read more →

JSON Schema for the Heroku Platform API

Today we’re making an important piece of Platform API tooling available: A machine-readable JSON schema that describes what resources are available via the API, what their URLs are, how they are represented and what operations they support. The schema opens up many interesting use cases, both for users and for us at Heroku working on improving and extending the API. A few examples are:

  • Auto-creating client libraries for your favorite programming language
  • Generating up-to-date reference docs
  • Writing automatic acceptance and integration tests

We are already using the schema to maintain the API reference documentation on Dev Center and to generate several v3 client libraries:

Of these, Heroics is officially supported by Heroku and the other three are community projects created by Heroku engineers. If you find bugs or have suggestions for enhancements, please send a pull request. We’re interested in having even more client libraries and hope hackers in the Heroku community will start building libs for other languages, either auto-generated ones using JSON Schema or hand-written ones.

Read more →

Programmatically release code to Heroku

Currently in beta, the Heroku Platform API lets developers automate, extend and combine the Heroku platform with other services in a programmatic, self-service way. Today we are setting the capstone into the API by adding slug and release endpoints to the API beta.

These API endpoints are special. They expose a very core part of what Heroku does best: Quickly and safely releasing new versions of an app onto the Heroku platform.

Using the new slug and release endpoints, platform developers can build integrations and services that completely sidestep the traditional Heroku Git deployment flow. So instead of requiring git push heroku master to deploy, it’s now possible to do things like:

  • Write a script that builds an app in a local directory on your machine, tars it up, and deploys it directly to a Heroku app
  • Extend your favorite continuous integration server or service to deploy directly to Heroku if unit tests pass – no need to use Git or manage SSH keys
  • Move slugs around between Heroku apps, for example to promote a release on a staging app to a production app

Are you a CI service provider, source code repository provider, or just a plain old hacker interested in the opportunities this opens up? We want to work with you, get in touch with friis@heroku.com.

The slug and release endpoints complete the functionality that we plan to expose in the first version of the Heroku Platform API. The API is still in beta and we welcome questions and feedback in the Heroku API Forum.

Read more →

Browse the blog archives or subscribe to the full-text feed.