With the addition of the Deploy to Bluemix button it is easier than ever to point someone at your public DevOps Services project and get them to a running example in minutes. The challenge is this that this requires some foresight to ensure that it works as expected in most scenarios and with minimal intervention from the “new” user whom is likely unfamiliar with the application.

First using the Deploy to Bluemix button itself. This requires that you have a public DevOps Services project using Git, for example I have cloned a the repository used in a developerWorks article¹ to create this repo swilbur/trendsapp Now if I want to create a new button I just need to use the following syntax to embed a link.

Copy and modify one of the following snippet templates and include a valid public Git repository:

HTML:

<a href="https://bluemix.net/deploy?repository=<git_repository_URL>"><img src="https://bluemix.net/deploy/button.png" alt="Deploy to Bluemix"></a>

Markdown:

[![Deploy to Bluemix](https://bluemix.net/deploy/button.png)](https://bluemix.net/deploy?repository=<git_repository_URL>)

So that part is easy enough, the challenge is that when you expect others to deploy your application you want that to happen automagically.

One problem that is easy enough to solve, is the route contention issue. As part of any CloudFoundry application there is normally an associated route and domain to access the application, this is fine when you are the only one deploying it to have a hardcoded value, and assuming that most users will share a common domain means that if you get more than one running then someones deployment will fail with a route already taken error. The simple fix for a scenario like sharing via a Deploy button is to just to have CF generate a random route for you.

---
applications:
  name: trendsapp
  random-route: true
  memory: 256M
  buildpack: python_buildpack

In this case the user just needs to inspect the url returned post-deployment to figure out where to point the browser, and be warned they are long but use words to make them slightly easier to manage for humans. Deploying this app for example gave me a url of http://trendsapp-dermatophytic-shipentine.mybluemix.net

The next problem that will trip up new users is the fact that they immediately have to deal with any dependent services that the application may require. For this CloudFoundry manifest files do support the notion of dependencies to help here. Our first improvement is to add a dependent service declaration to fail deployment if this service does not exist.

---
applications:
- services:
  - mydb01
  name: trendsapp
  random-route: true
  memory: 256M
  buildpack: python_buildpack

Now when we try and deploy we receive and error that mydb01 does not exist, so it at least stops an application from coming up that we know is non-functional.

IBM has added an extenion to the manifest.yml file to support just this scenario. The feature adds a new stanza to the manifest.yml file named declared-services that effectively extends this dependency declaration to include the intial bootstrapping of services that do not already exist.

---
applications:
- services:
  - mydb01
  name: trendsapp
  random-route: true
  memory: 256M
  buildpack: python_buildpack

declared-services:
  mydb01:
    label: mongodb
    plan: 100

With this complete example you should now be able to deploy your own copy of this application with a single click of this button (Assuming you are already logged in to Bluemix).

Reference:

• Deploy to Bluemix button doc
• developerWorks - Share with the Deploy to Bluemix button
• cloudfoundry docs - manifest.yml
• Bluemix docs - CF extension for declared services

Footnotes: