Deploying from a Pipeline

Build and test stages prove the code works. The deploy stage is where it actually starts running somewhere real - and where mistakes are the most expensive, so it deserves its own habits.

Build once, promote everywhere

A common mistake: rebuilding the application separately for dev, staging, and production. That means three different builds, and no real guarantee they're identical.

The fix: build one artifact (a jar, a Docker image, a zip of static assets), and promote that exact same artifact through each environment:

build → artifact.zip → deploy to dev → deploy to staging → deploy to prod

If it passed staging, production is getting the literal bytes that were tested - not a "should be the same" rebuild.

Common deploy steps

A deploy stage in a Jenkinsfile is usually just shell commands wired up to move that artifact somewhere and restart a service:

stage('Deploy') {
  steps {
    sh 'scp build/app.jar deploy@prod-server:/opt/app/'
    sh 'ssh deploy@prod-server "systemctl restart app"'
  }
}

rsync is a frequent upgrade over plain scp for anything bigger than a single file, since it only transfers what actually changed.

Rollback is part of the plan, not an afterthought

The deploy stage that matters most is the one that hasn't failed yet. Keep the previous artifact around, and know exactly how you'd restore it:

• Re-deploy the last-known-good artifact.
• Or keep two environments ("blue" and "green") and just flip which one receives traffic.

A deploy step without a rollback plan isn't really a safety net - it's a bet.

Try it

ssh deploy@prod-server

When you're ready, hit Mark complete and move to the next lesson.