Continuous Deployment Made Simple

Imagine you’re building a blogging app where users can read posts, filter them by tags or dates, and admins can add or edit posts. You’ve just finished a new feature—say, a tag-filtering system—and you’re excited to share it with the world. But deploying it manually means uploading files, running tests, and praying nothing breaks. What if your changes could go live instantly, safely, and without the hassle? That’s where Continuous Deployment (CD) comes in.

CD automates releasing your code to production every time you push a change, as long as it passes tests. It saves time, cuts errors, and lets you focus on building—like perfecting that blogging app. Today, we’ll use this app as our example to explore CD, from preview deployments to custom pipelines.

Here’s a question: How many of you think deploying is just “pushing code live”? It’s more than that—and doing it wrong can crash your app or frustrate users!

Section 1: Busting Myths and Setting Up CD with GitHub Branches

Common Misconceptions

Think, “Deploying every change instantly will break everything”? Nope! CD uses automation and tests to stay safe. Or, “CD is only for big teams”? Wrong—it’s for anyone who wants efficiency, even solo devs.

How It Works with GitHub Branches

For our blogging app, say you’re adding a “filter by date” feature on a branch called feature/date-filter. With CD, you get preview deployments—temporary versions of your app for that branch. Test it live without risking the main site.

The flow:

1. Push to feature/date-filter.
2. A CD tool detects the change.
3. It builds and deploys a preview—e.g., date-filter.feature.myblogapp.com.
4. Test it, fix bugs, then merge to main for production.

Handling DNS for Previews

How does date-filter.feature.myblogapp.com just work? Tools like Vercel (more on this soon) manage DNS automatically. They assign subdomains to each branch using a wildcard DNS record (e.g., *.myblogapp.com). When you push, their system maps the branch name to a unique URL, no manual DNS tweaks needed. It’s like magic—but it’s just smart automation.

Section 2: Continuous Deployment with Vercel

What’s Vercel?

Vercel is a platform that simplifies CD, perfect for web apps like our blogging app. It hooks into GitHub, builds your code, and deploys it effortlessly. It includes advanced monitoring and logging tools, firewall, DDoS protection and much more.

Setting It Up

For our TypeScript React app:

1. Push to a GitHub repo.
2. Link it to Vercel’s dashboard.
3. Vercel detects your setup (e.g., package.json with a build script).
4. Push to a branch? Get a preview URL. Push to main? It’s live.

Expanding the Example

Add an admin “edit posts” feature on feature/admin-edit. Vercel deploys a preview at admin-edit.myblogapp.vercel.app. Test it, confirm it works, merge it—live on myblogapp.com instantly.

DNS in Action

Vercel’s wildcard DNS handles previews. You set a domain (e.g., myblogapp.com) in Vercel, and it creates subdomains like feature-admin-edit.myblogapp.vercel.app (or a custom domain if configured). No DNS fiddling—just push and test.

Pros and Cons

• Advantages: Quick setup, free tier, auto-scaling, DNS magic.
• Disadvantages: Less server control, ecosystem lock-in, costs scale with usage.

Section 3: Alternatives to Vercel

Other Options

• Netlify: Like Vercel, great for static sites. Pros: free tier, custom functions. Cons: weaker for complex backends.
• Heroku: Good for dynamic apps. Pros: multi-language support, scaling. Cons: slower deploys, costly.
• GitHub Actions: Custom control (see next). Pros: flexible, free for public repos. Cons: setup effort.

Comparing with Our App

Vercel or Netlify for the blog frontend; Heroku or GitHub Actions for a beefy admin backend. Match the tool to your needs.

Section 4: Building a Custom CD Pipeline with GitHub Actions and SSH

Why Custom?

For full control—like deploying to your own server—use GitHub Actions. Let’s deploy our blogging app to myblogserver.com by pulling code via Git.

Step-by-Step Example

1. Push to <strong>main</strong>: Finish “filter by tag” and merge.
2. GitHub Action Triggers: A workflow runs.
3. SSH + Git Pull: It connects to the server, pulls the latest code, and builds it there.

Sample workflow (.github/workflows/deploy.yml):

name: Deploy Blog App
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Deploy to Server
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_KEY }}
          script: |
            cd /var/www/blogapp
            git pull origin main
            pnpm install
            pnpm run build
            pm2 restart blogapp

• How It Works: The server has a Git repo clone. The action SSHs in, pulls from main, installs dependencies, builds, and restarts the app (e.g., a Node.js process).
• Expanding It: Add npm test on the server before building, or use a staging branch for previews (though DNS would need manual setup or a tool like Nginx).

Pros and Cons

• Advantages: Total control, leverages Git, works anywhere.
• Disadvantages: Server maintenance, no auto-DNS for previews, setup time.

Conclusion

Key Takeaways

CD speeds up deployment with safety. GitHub branches and tools like Vercel give previews (with DNS handled via wildcards). Vercel’s easy for web apps; custom pipelines with Git pull suit complex needs. For our blogging app, Vercel could handle user filters, while a Git-based SSH pipeline powers the admin.

Best Practices

• Test before deploying.
• Use previews to catch issues.
• Choose tools based on complexity.

Pitfalls to Avoid

• Don’t skip tests—automation needs guardrails.
• Don’t over-engineer; start simple, then customize.

You’re now ready to deploy like pros—making that blogging app shine with every push!