Deployadactyl Versions Save

Added

• v3 api endpoints
• In addition to deploying, applications can now be started and/or stopped in a consistent manner across multiple CF instances.
• A new event handling framework has been introduced to give clear definition of the information available with each event. Events are now strongly typed and are subscribed to using functions strongly bound to the event type.

Deprecated

• v2 api endpoints
• The old event subscription framework has been deprecated and may be removed at some point in the future.

Programmatic Invocation Deployadactyl can now be invoked programmatically in addition to the previous invocation via HTTP request.

Deployment ID A deployment ID can now be passed to the deployment (when invoking programmatically) instead of Deployadactyl generating a new ID. If an ID is provided, Deployadactyl will use this ID for logging. This allows for deployment log correlation between Deployadactyl logging and logging output from your module.

Everything new since v.0.8.0

Features in this release:

• Added a route mapper event handler to support old versions of the Cloud Foundry CLI

Bugs fixed in this release:

• Fixed deployments failing when a domain isn't specified in the config

Features in this release:

• Made domain optional in the config.yml
• Deployadactyl will now remove the route before deleting the app to give the application a little extra time to gracefully shutdown
• Add an option health_check_endpoint parameter to the request that will double check the application is alive before moving on to the finish push

Features in this release:

Change the way Deployadactyl does blue/green deployment. The new approach is as follows:

• We no longer rename the existing application that is running when the push starts.
• We instead push a new version that is appname-new-build-UUID. Note: this new application will still share the same route as appname.cf.*.com
• If pushing the new application is successful, we delete the existing application and then rename the appname-new-build-UUID to appname
• If pushing the new application fails, we can simply delete it without touching the existing application that was running

This new process fixes an issue where two deployments of a broken build of the same application at the same time would end up deleting the existing application. This new process also simplifies the existing blue/green.

Bugs fixed in this release:

• fix the weird error message when an invalid environment is chosen

Features in this release:

• Add domain from the config to the deploymentInfo
• Add identifier around the Cloud Foundry output to make it easier differentiate between the individual deployment.

Bugs fixed:

• Saved artifacts were not being trashed due to the weird way go defer's work
• Fix manifest in JSON not being decoded

Features in this release:

• Venerable application instances are rolled back at the start of the deployment if they exist
• Updated the logs to be more consistent
• User receives the correct status codes in the response
• User can set default number of instances in the config
• Adds a Table of Contents to the README
• Adds CF CLI command for cf cups

Features in this release:

• User is able to push a local app file by sending it as a part of the request body. Documentation can be found in the wiki
• Deployer sends back the correct status codes
• Existing Venerable app instances are trashed before a deployment

• User receives cf logs on deployment failure
• Adds a config property for not rolling back first deployment
• Set KeepAlive to false in Artifetcher