A Beginner's Guide to Setting Up Continuous Deployment

You’ve probably heard the term “continuous deployment” thrown around in developer circles, and it sounds like something only senior engineers at big companies do. But the truth is, setting up a basic continuous deployment pipeline is easier than you think, and it can save you hours of manual work every week.

Let’s walk through what continuous deployment actually means, and then I’ll show you a simple, practical setup you can implement today.

What is Continuous Deployment?

Continuous deployment is the practice of automatically deploying every code change that passes your tests directly to production. No manual clicks, no waiting for a release day. Every time you push code to your main branch, if the tests pass, the code goes live.

This is different from continuous delivery, where you automate the testing and packaging but still need a human to press the deploy button. With continuous deployment, the button is pressed for you.

Why Bother?

The biggest benefit is speed. When you fix a bug or add a feature, it reaches your users in minutes instead of days. This means faster feedback loops and less context switching for developers. You don’t have to remember what you were working on two weeks ago when a release finally goes out.

Another advantage is reduced risk. When you deploy small changes frequently, each deployment is less scary. If something breaks, you know exactly which change caused it, and rolling back is straightforward.

What You’ll Need

Before we dive into the setup, make sure you have these basics in place:

• A Python project with automated tests (pytest is a great choice)
• A Git repository hosted on GitHub, GitLab, or Bitbucket
• A server or cloud platform where your app will run (like Heroku, DigitalOcean, or AWS)
• A CI/CD service (GitHub Actions, GitLab CI, or CircleCI all work well)

If you don’t have tests yet, start there. Continuous deployment without tests is like driving a car without brakes. You’ll move fast, but you won’t be able to stop when something goes wrong.

Step 1: Write a Simple Test

Let’s say you have a Flask app that returns a greeting. Here’s a basic test using pytest:

# test_app.py
from app import app

def test_homepage():
    response = app.test_client().get('/')
    assert response.status_code == 200
    assert b'Hello' in response.data

Run it locally first to make sure it passes. If you don’t have pytest installed, add it to your requirements.txt file.

Step 2: Set Up Your CI/CD Pipeline

I’ll use GitHub Actions for this example because it’s free for public repositories and easy to get started with. Create a file at .github/workflows/deploy.yml in your repository.

Here’s a basic workflow that runs tests and then deploys:

name: Deploy to Production

on:
  push:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'
      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt
      - name: Run tests
        run: pytest

  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Deploy to server
        run: |
          # Your deployment script goes here
          echo "Deploying to production..."

This workflow does two things: it runs your tests first, and only if they pass does it proceed to the deploy step. The needs: test line ensures that order.

Step 3: Choose Your Deployment Method

How you actually get your code onto your server depends on where you’re hosting. Here are three common approaches:

1. SSH and Git Pull If you have a VPS, you can SSH into it and run git pull. This is simple but requires setting up SSH keys in your CI environment.

2. Docker and Container Registries Build a Docker image, push it to Docker Hub or GitHub Container Registry, then pull it on your server. This is more complex but gives you consistent environments.

3. Platform-as-a-Service Services like Heroku or Railway let you connect your GitHub repo directly. Push to main, and they deploy automatically. This is the easiest option for beginners.

A Real Example with Heroku

Let’s say you’re using Heroku. First, install the Heroku CLI and create an app:

heroku create my-python-app

Then, add a Procfile to your project root:

web: gunicorn app:app

Now, in your GitHub Actions workflow, add a step to deploy to Heroku:

- name: Deploy to Heroku
  uses: akhileshns/heroku-deploy@v3.12.12
  with:
    heroku_api_key: ${{ secrets.HEROKU_API_KEY }}
    heroku_app_name: "my-python-app"
    heroku_email: "your-email@example.com"

You’ll need to generate a Heroku API key from your account settings and add it as a secret in your GitHub repository. Go to Settings > Secrets and variables > Actions, then add HEROKU_API_KEY.

Step 4: Test the Pipeline

Push a small change to your main branch. Watch the Actions tab in GitHub. You should see the workflow run, tests pass, and then the deploy step execute. Within a minute or two, your change should be live.

If something fails, the pipeline stops. That’s the safety net. You’ll get a notification, and you can fix the issue before it reaches users.

Common Pitfalls to Avoid

Skipping tests – I know it’s tempting to push without tests when you’re in a hurry, but that defeats the purpose. Even a single test that checks if your app starts up is better than nothing.

Deploying secrets in plain text – Never hardcode API keys or database passwords in your code. Use environment variables and store secrets in your CI/CD platform’s secret manager.

Not having a rollback plan – Before you automate deployments, make sure you know how to revert to a previous version. Heroku makes this easy with heroku releases:rollback. For other platforms, keep your last working Docker image tagged.

A Simple Deployment Script

If you’re deploying to a Linux server via SSH, here’s a basic script you can use:

#!/bin/bash
ssh user@yourserver.com "cd /var/www/myapp && git pull && source venv/bin/activate && pip install -r requirements.txt && systemctl restart myapp"

Store your SSH private key as a GitHub secret and use it in your workflow like this:

- name: Deploy via SSH
  run: |
    echo "${{ secrets.SSH_PRIVATE_KEY }}" > key.pem
    chmod 600 key.pem
    ssh -i key.pem user@yourserver.com "cd /var/www/myapp && git pull && source venv/bin/activate && pip install -r requirements.txt && systemctl restart myapp"

What About Database Migrations?

This is where many beginners get stuck. If your deployment involves database schema changes, you need to handle migrations carefully. The safest approach is to run migrations before deploying the new code, so the database is ready for the new application version.

In your deployment script, add a migration step:

flask db upgrade

But be careful: if the migration fails, you don’t want to deploy the new code. So run migrations as part of the deploy step, not before it.

Monitoring Your Deployments

Once you have continuous deployment running, you need to know if something goes wrong. Set up basic health checks. For example, after deployment, your CI pipeline can hit your app’s health endpoint and verify it returns a 200 status.

You can also use free tools like UptimeRobot to ping your site every five minutes and alert you if it goes down.

When Not to Use Continuous Deployment

Continuous deployment isn’t right for every project. If you’re building a medical device or a banking application, you probably want more manual oversight. Also, if your user base is small and you’re the only developer, the time saved might not justify the setup effort.

But for most web applications, APIs, and internal tools, continuous deployment is a game changer. It forces you to write better tests, keeps your deployment process documented, and makes your team more responsive.

Your First Deployment

Start small. Pick one project that isn’t mission-critical. Set up the pipeline I described above. Push a tiny change—maybe update a CSS color or fix a typo. Watch it go live automatically.

Once you see how smooth it is, you’ll wonder why you didn’t do this sooner. And that’s the moment you’ll start looking at all your other projects thinking, “I should set this up for that one too.”

Continuous deployment isn’t just for big tech companies. It’s a practical tool that any Python developer can use to ship better software, faster. Give it a try this week, and see how it changes your workflow.