Forem: Andrew Magill

Automating a Full-Stack, Multi-Environment Deployment Pipeline With Github Actions

Andrew Magill — Mon, 08 Dec 2025 13:04:20 +0000

I have a confession to make, I am terrible at remembering all the different deployment checks and publishing chores for each of my projects. It's embarrassing, I know. Now that the air has been cleared, let's find a way to compensate for my shortcomings.

In my latest project, I'll set up a full-stack multi-environment deployment pipeline using GitHub Actions. This has been so incredibly useful, I decided to share some details about why I chose this configuration and the benefits of this approach:

But Why?

For my project, I needed a safe space to test code changes before they went live. Local development has it's place, but you know it can be a pain for applications hosted on multiple environments. A staging platform provides a valuable resource for stakeholder reviews, facilitating regular feedback and deeper collaboration. This setup allows me to push changes where they are needed, and automagically perform any steps required for each environment. I shake my head when I think about all the time I wasted doing this manually.

Laying the Pipeline

I organized my repository into separate branches to accommodate each environment: main for production and develop for staging. Don't forget, this is a full-stack app, with front and backend hosted on different environments. This pipeline uses two Sync-to-FTP actions with separate credentials to deploy both front and backend to their respective servers. If you've ever mistakenly pushed the wrong files to the wrong server, you understand how helpful this is.

To control each environment independently, we can use environment-specific configurations. My staging environment uses a separate database, different API keys, and its own settings. GitHub Actions repository secrets simplify automating anything that varies between environments, like feature flags and API endpoints.

Conditional job execution allowed workflows to run differently depending on the branch. Staging can run a full suite of tests, providing confidence in the stability of the codebase. Production only gets a quick smoke test. To make it easier to inspect and debug code in the browser console, I disabled minification and enabled sourcemaps for the front-end on the staging environment. On production, minification was enabled to optimize performance and debug logging disabled to prevent accidental leaking of sensitive user data.

Access Control

One key benefit of this approach is access control. By granting developers access to specific branches, they automatically gain the ability to trigger deployments to the corresponding environments. Instead of juggling individual logins or shared credentials for each environment's hosting platform, I could manage access at the repository branch level. This not only streamlined onboarding and offboarding but also significantly improved security.

Workflow Procedure

Workflows are triggered by pushes to the relevant branches. In my workflow, a push to develop triggers the staging deployment, and a push to main triggers the production deployment.

The front-end build process uses npm run build which runs the front-end build process (which is defined in package.json, silly). On staging, we can specify separate configuration files, with the --config dev.config.js flag to customize build process more precisely. This back-end build uses a generic composer install action, which could be customized further.

Here's a more detailed snippet, tying it all together:

name: Deploy Main to LIVE FTP
on:
  push:
    branches:
      - main
jobs:
  FTP-Deploy-Action:
    name: Deploy to LIVE Action
    runs-on: ubuntu-latest
    steps:
    - name: Get latest code
      uses: actions/checkout@v4

    - name: Use Node.js 18
      uses: actions/setup-node@v4
      with:
        node-version: '18'

    - name: Build Front
      run: |
        npm install
        npm run build
      working-directory: ./front/

    - name: Sync Front Files
      uses: SamKirkland/FTP-Deploy-Action@v4.3.5
      with:
        server: ##.###.##.###
        username: frontuser
        password: ${{ secrets.front_ftp_password }}
        protocol: ftps
        local-dir: ./front/
        server-dir: /front/

    - name: Setup PHP
      uses: "shivammathur/setup-php@v2"
      with:
        php-version: "latest"

    - name: Build Backend
      uses: "ramsey/composer-install@v3"
      with:
        working-directory: ./back/

    - name: Sync Back Files
      uses: SamKirkland/FTP-Deploy-Action@v4.3.5
      with:
        server: ##.###.##.###
        username: backuser
        password: ${{ secrets.back_ftp_password }}
        protocol: ftps
        local-dir: ./back/
        server-dir: /back/

To be continued...

This multi-environment deployment pipeline has been working great. The simplified access control and the ability to customize build processes for each environment have made deployments easier and faster, freeing me up for other stuff. Because everything is baked into the pipeline, I don't need to remember all the minutiae and procedures required to safely publish projects that use this approach. There are endless ways this approach could be adapted to other projects, and I'm eager to explore what else these methods can accomplish.

Boosting My NextJS Blog’s Visibility with RSS

Andrew Magill — Thu, 04 Dec 2025 15:32:20 +0000

RSS (Really Simple Syndication) is a useful tool for publishers, bloggers, and creators to boost their content's visibility. By adding RSS to my static NextJS blog, I’m hoping to expand my website's reach and make it easier to share my content with a broader audience. So, let’s explore the benefits of RSS and how I’ve sprinkled it on my blog like confetti at a party!

Reach and Discoverability

RSS is the standard solution for content syndication on the web, allowing content to be shared across multiple websites and social media channels with minimal effort. I plan to use this capability to cross-post my content to the developer community site, Dev.to. This should be a good method to gain some exposure and boost my online presence—because let’s face it, shouting into the void isn’t exactly effective.

This is just one method to help prevent my content from getting lost in the digital abyss. Content aggregators can expose my posts to potential readers who probably will not stumble on my blog through other means. This gives my site extra exposure and potential backlinks that could boost SEO credibility. It’s a win-win!

The Right Tools

I'll use the rss npm library to generate an RSS feed into my static NextJS blog. It's a straightforward library that simplifies the process and integrates seamlessly with my project. This way, I can focus on creating content instead of wrestling with XML schemas or other maintenance headaches.

Now, let’s get down to configuring that shiny new RSS feed of ours.

Generate Feed Content: To start, we can create a utility function to generate our feed content

import { Rss } from 'rss';
import { settings } from '@/utils/settings.mjs'; // site settings
import postService from '@/utils/PostService'; // post service utility

const getPostFeed = (posts = []) => {
    // set feed values from site settings
    const feed = new Rss({
        title: settings.title,
        description: settings.description,
        site_url: settings.siteUrl,
        feed_url: `${settings.siteUrl}/feed/posts.xml`,
        language: 'en',
        date: new Date(),
    });

    // Get post data
    posts = posts.length > 0 ? posts : postService.getPosts();

    posts.map((post) => {
        // add post data to feed
        feed.item({
            title: post.title,
            guid: `${settings.siteUrl}/post/${post.slug}`,
            url: `${settings.siteUrl}/post/${post.slug}`,
            date: post.created,
            description: post.description,
            author: post.author || settings.author,
            categories: post.categories || [],
        });
    });

    return feed;
};
export { getPostFeed };

You can checkout my most recent version of that utility function in this site's repo on GitHub. Someday I'll create a unit test for that function, pinky swear, but for now...

Route the Feed: Then, we can "feed" our blog data into an API route.tsx

import { getPostFeed } from '@/utils/feed.mjs'; // the feed utility function from above

export async function GET() {
    const feed = getPostFeed();

    return new Response(JSON.stringify(feed.xml()), {
        headers: { 'Content-Type': 'application/json; charset=utf-8' },
    });
}

Easy peasy lemon squeezy, as the kids like to say. You can see my latest implementation of this includes a dynamic route segment to serve different versions of the post feed.

Build for Production: Finally, lets run the build process to kick out the jams :

npm run build

New posts and content changes will now auto-magically show up in the feed.xml. Excelsior!

Next.js Dynamic Routing for RSS Feeds

Let’s see how the RSS feed is actually served in my Next.js app, using a dynamic API route. Here’s a simplified version of my app/feed/[type]/route.tsx file:

import { NextResponse } from 'next/server';
import postService from '@/utils/PostService';
import { getPostFeed } from '@/utils/feed';

export const generateStaticParams = async (): Promise<{ type: string }[]> => {
    const params = ['posts.xml', 'posts.json'].map((type) => ({ type }));
    return params;
};

export async function GET(
    request: Request,
    { params }: { params: { type: string } }
) {
    if (params.type === 'posts.xml') {
        // Serve up the RSS feed
        const feed = getPostFeed();
        return new Response(feed.xml(), {
            headers: {
                'Content-Type': 'application/rss+xml; charset=utf-8',
            },
        });
    } else if (params.type === 'posts.json') {
        // Serve up posts as JSON
        const posts = postService.getPosts();
        return new Response(JSON.stringify(posts), {
            headers: {
                'Content-Type': 'application/json; charset=utf-8',
            },
        });
    } else {
        return new Response('Not Found', { status: 404 });
    }
}

This route handles requests for both /feed/posts.xml (RSS) and /feed/posts.json (raw article data). When a request is made, it generates the RSS feed using the utility function and returns it with the correct content type. This approach leverages Next.js’s file-based routing and makes it easy to add or modify feed formats in the future (im looking at you emerging AI protocols).

The Closing Tag

So, I’ve finally implemented RSS in my NextJS blog—because who doesn’t want to dive into the exciting world of content syndication, am I right? Using the rss library to generate the feed at build-time was fairly straight-forward. As I publish fresh content, fingers crossed that this setup will help me reach an audience without resorting to begging or spamming.