Automate Web Portal Deployment in Minutes Using GitHub Actions

In today's fast-paced development environment, automating the deployment process is crucial for maintaining efficiency and reducing human error. GitHub Actions has emerged as a powerful tool for implementing continuous integration and continuous deployment (CI/CD) pipelines, particularly for web applications. This article explores how to leverage GitHub Actions to deploy a feedback portal seamlessly and efficiently.

The Power of GitHub Actions

GitHub Actions is more than just a CI/CD tool; it's a complete automation platform that allows developers to create custom workflows for building, testing, and deploying their applications. These workflows are triggered by specific events in your GitHub repository, such as pushes, pull requests, or scheduled tasks.

Setting Up Your Deployment Workflow

Creating the Workflow File

The heart of your deployment process with GitHub Actions lies in the workflow file. This YAML file, typically named deploy.yml, should be placed in the .github/workflows/ directory of your repository.

Here's an expanded example of a workflow file for deploying a feedback portal:

This workflow does the following:

1. Triggers on pushes of the main branch
2. Sets up a Node.js environment and caches dependencies for faster builds
3. Installs dependencies, runs tests, and builds the project
4. If all previous steps succeed and the event is pushed to main, it deploys a feedback portal App on to given server.

name: Deploy Feedback Portal
on:
  push:
    branches:
      - main

jobs:
  build_and_test:
    runs-on: [ubuntu-latest, self-hosted]

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '16'

      - name: Cache dependencies
        uses: actions/cache@v3
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

      - name: Build project
        run: npm run build

   deploy:
    needs: build_and_test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Deploy to On-Prem Server
        run: |
          # Using secrets for username and password (or SSH key)
          scp -r ./dist/ ${{ secrets.SERVER_USER }}@your-server:/path/to/your/application
          ssh ${{ secrets.SERVER_USER }}@your-server "cd /path/to/your/application && ./restart-service.sh"
          
        # If you are using an SSH key
        env:
          SSH_PRIVATE_KEY: ${{ secrets.ONPREM_SERVER_SSH_KEY }}
        run: |
          echo "${SSH_PRIVATE_KEY}" > keyfile
          chmod 600 keyfile
          scp -i keyfile -r ./dist/ ${{ secrets.SERVER_USER }}@your-server:/path/to/your/application
          ssh -i keyfile ${{ secrets.SERVER_USER }}@your-server "cd /path/to/your/application && ./restart-service.sh"

Explanation

1. Secrets in GitHub Actions

• ${{ secrets.SERVER_USER }}: This will be replaced with the actual value of the user’s name that you stored as a secret in the GitHub repository.
• ${{ secrets.SERVER_SSH_KEY }}: This is where the private SSH key is securely accessed for deployment.

2. SSH Key Authentication

If you are using SSH keys for authentication, you can add the SSH private key as a secret (e.g., SERVER_SSH_KEY). The key is temporarily saved in the workflow as a file (keyfile), and scp and ssh commands use it to securely transfer files and restart the service.

3. Environment Variables

The env key is used to pass secrets like the SSH private key as environment variables in the workflow.

4. Triggering the Workflow

The workflow is triggered whenever code is pushed to the main branch.

5. Jobs

• build_and_test: This job installs dependencies, runs tests, and builds the application.
• deploy: This job deploys the application to your on-prem server after the build is successful.

6. Workflow Steps

• actions/checkout@v4: Checks out the repository code
• actions/setup-node@v3: Sets up Node.js version 16 for the environment
• actions/cache@v3: Caches npm dependencies to speed up future builds; It uses the package-lock.json file to generate a unique cache key. If the lock file changes, a new cache will be created, otherwise, it will restore from the cached dependencies.
• npm ci: Installs the dependencies specified in the package-lock.json file, ensuring a clean and reproducible environment
• npm test: Runs tests to ensure the application works as expected
• npm run build: Builds the application, typically creating production-ready assets in a dist folder
• Deploy to On-Prem Server: Uses scp to transfer the built files to your on-prem server and ssh to execute a script that restarts the application.

Environment-Specific Deployments

For more sophisticated deployment strategies, you can use GitHub Environments to manage different deployment targets:

jobs:
  deploy_to_staging:
    runs-on: ubuntu-latest
    environment: staging
    steps:
      # Deployment steps for staging

  deploy_to_production:
    needs: deploy_to_staging
    runs-on: ubuntu-latest
    environment: production
    steps:
      # Deployment steps for production

This setup allows you to define specific protection rules and secrets for each environment, ensuring a controlled and secure deployment process.

Configure Your On-Prem Server

#!/bin/bash

cd /path/to/your/application
# Stop the currently running service
sudo systemctl stop feedback-portal
# Deploy new changes (clear the old build and move the new files)
sudo rm -rf /var/www/feedback-portal/*
sudo cp -r dist/* /var/www/feedback-portal/
# Restart the service
sudo systemctl start feedback-portal

Artifact Management

For multi-stage deployments or when you need to pass build outputs between jobs, use artifacts:

- name: Upload artifact
  uses: actions/upload-artifact@v3
  with:
    name: dist
    path: dist

In a later job:

- name: Download artifact
  uses: actions/download-artifact@v3
  with:
    name: dist

This allows you to build once and deploy to multiple environments without rebuilding.

Repository Structure

A typical structure for your feedback portal repository might look like this:

feedback-portal/
├── .github/
│   └── workflows/
│       └── deploy.yml
├── config/
│   ├── config.json  # Configuration file
│   └── other-config-files.json
├── src/             # Application source code
│   ├── components/   # Frontend components
│   ├── services/     # Backend services
│   └── index.js      # Entry point for your application
├── tests/           # Test files
│   └── example.test.js
├── package.json     # npm package file
├── package-lock.json # npm lock file
└── README.md        # Project documentation

Key Components of the Repository

.github/workflows/

This directory contains your GitHub Actions workflows. Here, you have deploy-feedback-portal.yml to deploy your application and update-portal-config.yml for managing configuration updates.

config/

This directory should hold all configuration files for your portal, such as config.json, which contains settings for the application (e.g., database connections, API keys).

src/

This is where your application’s source code will live. Organize your code into subdirectories for better maintainability. For instance, you might have a components/ directory for front-end components and a services/ directory for backend API services.

tests/

A directory for your test files, ensuring that you can run tests to validate the functionality of your code.

package.json and package-lock.json

These files are used by npm to manage dependencies for your project. The package.json file defines your project and its dependencies, while the package-lock.json ensures that the same versions of dependencies are installed every time.

By organizing your feedback portal code in a structured manner within your GitHub Enterprise repository, you facilitate easier collaboration, management, and deployment.

With the workflow and server configuration in place, you now have a fully automated CI/CD pipeline that builds, tests, and deploys your feedback submission portal to an on-prem server. This setup leverages GitHub Enterprise and GitHub Actions, ensuring that your deployments are consistent, secure, and reliable, all while staying within your internal infrastructure.

By customizing this workflow, you can deploy other types of applications, integrate further testing steps, or enhance security as needed.

Conclusion

GitHub Actions offers a robust and flexible platform for automating web portal deployments. By leveraging its features — from basic workflows to advanced configurations like environment-specific deployments and matrix builds — developers can create efficient, secure, and scalable deployment pipelines.

As you implement these strategies, remember that the key to successful automation is continuous refinement. Regularly review and optimize your workflows, stay updated with the latest GitHub Actions features, and always prioritize security in your deployment processes.

By mastering GitHub Actions for web portal deployment, you're not just automating a task — you're adopting a philosophy of continuous improvement and efficiency that can transform your development workflow and give your team a significant advantage in delivering high-quality web applications.