How to ensure your application is available even during a deployment.
When updating an application with
cf push, there is some downtime while the application deploys.
While this may be okay during development, it usually is not for production. You can solve this by having
two copies of the application with a common route and updating them one at a time. This is called
Here is a basic
manifest.yml example for using blue/green deploys:
... host: app-name applications: - name: app-name-blue - name: app-name-green
This file will:
- Create a
hostat app-name.apps.staging.digital.gov.au. This is where you can view your application
- Create two applications:
Users will route to either app-name-green or app-name-blue when they visit
When you run
cf push to update this application, it will first update
- Unmap the route from
app-name-blue, causing all traffic to go to
- Update the files for
- Remap the route from
app-name-blue, causing traffic to split between the two apps
Then it will do the same thing for
app-name-green. This ensures the user
never experiences any downtime.
Using a database
If your application requires a database, you will usually use the same database for the blue and green applications. This ensures that users have the same view of the data regardless of which app they are viewing.
This can make it harder to do database migrations. If the start command performs the database migration, the migration will run twice, once by the blue app and once by the green app. There is also a period where the green app is running the old code against the new database. To handle these issues, keep these principles in mind.
- Database migrations should have the same effect regardless of how many times they execute
- The new version of the database should work with both the old and new versions of the code