Deployments

Deployment Engines

A deployment pushes a version of the application to an environment, through one of five engines.

Where to find it

Architect Panel → Integration & Connections:

• Deployments — the console, environments and versions

Architect Panel → Configuration:

• Site Settings — the deployment target

The five engines

• AWS Beanstalk — for autoscaling cloud estates.
• SFTP and FTP/FTPS — conventional hosting.
• Network Drive and Local Folder — on-premises and development.

Which you use is generally decided by how you are hosted rather than by preference.

Environments

Deployments target named environments — live, development, test. Having them named and separate is what makes it possible to try a version somewhere before it reaches users.

Database changes are not part of this

The point most worth being clear about. Deploying the application does not apply schema changes, and rolling a deployment back does not undo them.

So a release involving both is two exercises with two rollback plans, sequenced deliberately. Treating them as one is how a rollback leaves an application running against a schema it does not expect.

Credentials belong to the organisation

Deployment credentials reach your production environment. They should not be a person's, and they should be rotated when somebody with access leaves.

Deploy at a sensible time

When people are available. The engine does not care; your users do, and so does whoever has to diagnose a problem.

Check afterwards

That the version is what you intended, that the application responds, and that the error log is clean. A deployment that reported success and produced a broken application is not unusual, and nothing will tell you.

Know the rollback

Before deploying, not after. Which version you would go back to and how — and confirm somebody other than you knows it.

Worked example

An organisation deploys to a test environment first, exercises a written list of checks, then deploys to live on a Tuesday morning. Schema changes are applied as a separate step with their own rollback script, before the application version that needs them. The error log is reviewed after each.

Recommendations

• Deploy to a non-production environment first.
• Treat schema changes as a separate exercise.
• Use organisational credentials and rotate them.
• Know the rollback before you start.

Deploying to AWS

The AWS Beanstalk engine deploys application versions to a managed cloud environment.

Where to find it

Architect Panel → Integration & Connections:

• Deployments — environments and versions

Architect Panel → Integration & Connections:

• Database Hosts — where the data lives

What it gives you

• Autoscaling — capacity following load.
• Managed environments — live, test and others, each independent.
• Versioned deployments, so a specific version can be re-applied.
• Health checking, replacing instances that stop responding.

Point health checks at the right endpoint

The platform offers a liveness check that touches no database and a readiness check that does. The load balancer should use liveness.

If it checks the database, a brief database problem takes every instance out of service simultaneously — turning something recoverable into a total outage. Use readiness for monitoring instead.

Instances are disposable

They are replaced routinely. Anything written to an instance's own disk is lost, which matters for uploads, sessions and anything cached locally.

Sessions in particular need to be shared rather than held on the instance, or users are signed out whenever they reach a different one — which presents as random, intermittent sign-outs that are miserable to diagnose.

The database is separate

Deploying does not touch it, and scaling the application does not scale it. A database that is the constraint will not be helped by more application instances, and adding them can make it worse.

Watch the cost

Autoscaling responds to load, including load you did not intend — a runaway integration, a crawler, a badly configured poll. Set alarms on spend as well as on health.

Keep environments genuinely separate

Especially their credentials. A test environment holding live mail or payment credentials will eventually use them, and it will do so while somebody is testing something.

Deploy to test first

The whole point of having environments. A version that deployed cleanly to test is not guaranteed in live, but a version that failed in test certainly would have failed in live.

Worked example

An organisation runs live and test environments with sessions held in a shared store rather than on instances, the load balancer checking liveness and monitoring checking readiness. A database failover took forty seconds; monitoring alerted, no instances were replaced, and the site returned errors briefly instead of going down.

Recommendations

• Liveness for the load balancer, readiness for monitoring.
• Share sessions — instances are disposable.
• Separate environment credentials completely.
• Alarm on spend, not only on health.