Teams usually move to a deployment platform when their first setup stops scaling. A deploy script that worked for one environment gets copied for the second, and by the third there are several versions of it that differ in small ways.
What "traditional" deployment usually means
In practice it takes one of three forms. Each works for a while, and each breaks in a predictable way.
// Shape A
CI does it all
Build and deploy run in the same pipeline, and the deploy step is a script in the repository. This works until environments need different values and someone puts production credentials in the pipeline file.
// Shape B
Shell scripts on the build server
Build output is copied or zipped, and a script connects to each server over SSH to put it in place. This works until you need a rollback, or two engineers change the script at the same time.
// Shape C
Manual deployment
FTP, remote desktop, copy and paste, and a checklist. This works for a very small setup and causes most incidents once there is more than one server or person involved.
What a deployment platform changes
A platform like Jaws Deploy doesn't deploy faster than a shell script. It adds structure: more setup at the start, much less maintenance later, and a record of every deployment that doesn't depend on the person who wrote the script.
What changes when you adopt one
- Environments are objects with their own variable values, place in the lifecycle and history, rather than folder names in a build script.
- Releases can't change. What reached Staging is what reaches Production, with no rebuild in between.
- Variables are scoped. Connection strings belong to the environment instead of one large config file.
- Deployments are visible. Each step has a live log and a status, so a failure points to one step instead of the whole job.
- History is kept. You can see what changed between two deployments without searching CI logs.
When you don't need one
If you deploy to one environment, from one developer's machine, with one config file, a deployment platform adds more than it saves. It starts to pay off with two or more environments and more than one person deploying.
It is also one more tool to learn, and to run yourself if you self-host. Most of the benefit comes later, as environments and people are added.