Cloud Foundry is an open source cloud platform as a service (PaaS) on which developers can build, deploy, run and scale applications on public and private cloud models.


Developers interact with Cloud Foundry by running a command line tool (cf) which then interacts with the Cloud Foundry Endpoint. To deploy a new Application (or to make changes to an existing Application) developers uses the “cf push” command to upload the

Application to the Cloud Foundry Endpoint.


Cloud Foundry supports multiple “spaces”. Each space can be configured individually and can be used as different target types (for example, Dev, Test and Production).


Since DeployHub is an agentless solution it can deploy to Cloud Foundry by executing the cf command automatically as part of the deployment process. It can extract your DeployHub Application code from any Repository and push the changes up to the Cloud Foundry Endpoint automatically. It can then track which version of the Application is installed in which Cloud Foundry space.


Installing Cloud Foundry’s cf Command Line Interface (cf CLI) on the same server as DeployHub allows the execution cf commands easily using DeployHub. A DeployHub Application contains one or more Components, any one of which can have a Custom Action containing a cf command that targets the designated Clound Foundry Endpoint. For instance, a Cloud Foundry application named my_app could be started by writing a script named startMyApp.sh that looks like:


#!/bin/sh

cf api https://myexample.com

cf auth myname  mypassword

cf target -o myorg -s myspace

cf push `my_app` -c null


If this script resides within the /scripts directory of the DeployHub installation, it can be called by putting “/scripts/startMyApp.sh” into a Procedure, placing it within an Action, and putting the name of the Action into a Component’s Custom Action field. Deploying the Application that contains the Component causes the Action to be called, which runs the script and starts the Cloud Foundry Application named my_app.


Cloud Foundry is ideal for Blue-Green deployment strategies. In such a scenario, Production is mirrored across two distinct environments - “blue” and “green”. End Users point to one of these Environments whilst deployments are made to the other. Once testing is complete on the deployed Environment, users are switched over to this Environment and the deployment is performed again to the other Environment. This maximizes uptime and minimizes the risks in performing a Rollback.


DeployHub supports such a Blue-Green deployment strategy. Both Environments can be targeted individually as part of two separate deployments or you can deploy to both with DeployHub deploying to the second Environment automatically following successful test and switch-over.