Loading

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.