Real-World GitHub Actions Projects

# CHAPTER 19

Real-World GitHub Actions Projects #

1. Introduction #

In the DevOps industry, theoretical knowledge gets you the interview, but a demonstrated portfolio gets you the job. Employers want to see that you can synthesize multiple technologies—Git, Docker, Cloud Providers, and YAML—into a seamless, automated workflow. In this chapter, we outline five robust, professional-grade CI/CD projects. These projects are designed to prove your mastery of GitHub Actions syntax, security best practices, multi-stage deployments, and infrastructure automation.

2. Learning Objectives #

By the end of this chapter, you will be able to:

• Architect a complete CI/CD pipeline for a dynamic web application.

• Build a fully automated Docker containerization workflow.

• Orchestrate a deployment to a Kubernetes cluster via GitHub Actions.

• Design a reusable workflow architecture for an enterprise.

• Document and present DevOps projects professionally for a portfolio.

3. Project 1: End-to-End CI/CD Pipeline for a PHP/Node App #

The Goal: Prove you understand the fundamental CI/CD quality gate sequence. The Architecture:

1. 1. Source: A simple web application hosted on GitHub.

1. 2. Trigger: Execute on pullrequest to main.

1. 3. The Workflow:

• Job 1 (Test): Setup language, cache dependencies (actions/cache), run a Linter to fail fast, and execute Unit Tests (PHPUnit/Jest).

• Job 2 (Deploy): Requires needs: test. Authenticate via SSH Action and transfer files to a live DigitalOcean/AWS server using SCP.

1. 4. The Proof: Create a video showing a Pull Request with a deliberate typo. Show GitHub Actions blocking the merge button with a red X. Fix the typo, show the checks turning green, merge the PR, and show the live website updating automatically.

4. Project 2: Docker Hub Automation Workflow #

The Goal: Prove you understand immutable deployments and containerization. The Architecture:

1. 1. Source: Include a Dockerfile in your application repository.

1. 2. The Workflow:

• Trigger on a new Git Release / Tag (e.g., v1.0.0).

• Use docker/login-action to authenticate with Docker Hub using Encrypted Secrets.

• Use docker/setup-buildx-action to enable layer caching.

• Use docker/build-push-action to build the image and tag it dynamically with the GitHub Tag name AND the Commit SHA.

1. 3. The Proof: Document the pipeline output showing the successful image build, and provide a screenshot of the Docker Hub repository showing the newly pushed image with the exact version tags matching your GitHub release.

5. Project 3: Kubernetes Deployment Workflow (GitOps) #

The Goal: Prove you can interact with modern cloud-native orchestration. The Architecture:

1. 1. Source: A repository containing a k8s/deployment.yaml file.

1. 2. The Workflow:

• Authenticate with a cloud provider (GCP or AWS) using passwordless OIDC (OpenID Connect).

• Install kubectl on the GitHub runner.

• Execute kubectl apply -f ./k8s/deployment.yaml.

• Execute kubectl set image to update the cluster to the newly built Docker image.

• Execute kubectl rollout status to wait for deployment verification.

1. 3. The Proof: Provide screenshots of the GitHub Actions logs showing successful OIDC cluster authentication, and terminal output of kubectl get pods showing the old pods terminating and the new pods running without downtime.

6. Project 4: Enterprise Reusable Workflow Architecture #

The Goal: Prove you understand enterprise scalability and the DRY principle. The Architecture:

1. 1. Source: Create a separate repository named github-actions-templates.

1. 2. The Code: Write a highly parameterized Reusable Workflow (on: workflowcall) that enforces Dependency Installation, Security Scanning (e.g., Trivy or SonarQube), and Slack Notifications.

1. 3. The Implementation: Create a second "Caller" repository. Refactor its CI/CD pipeline to be less than 15 lines of YAML, relying entirely on the uses: my-org/github-actions-templates/.github/workflows/central.yml@v1 statement.

1. 4. The Proof: Provide the code for both repositories, highlighting how the complex security logic was abstracted away from the application developers, ensuring organizational compliance.

7. Project 5: Automated Infrastructure Provisioning (Terraform) #

The Goal: Prove you understand Infrastructure as Code (IaC) orchestration. The Architecture:

1. 1. Source: A repository containing Terraform .tf files defining an AWS EC2 instance.

1. 2. The Workflow:

• Trigger on pull_request to run terraform plan and use the actions/github-script action to post the plan directly as a comment on the Pull Request.

• Trigger on push to main to run terraform apply.

• Implement GitHub Environments to require a manual click-approval before the apply step executes.

1. 3. The Proof: Document the Pull Request comment showing the Terraform plan, the pipeline halting at the Environment approval stage, the successful execution of the apply command, and a screenshot of the newly created EC2 instance in the AWS Console.

8. How to Document Your DevOps Portfolio #

A DevOps portfolio is different from a software developer's portfolio. You aren't just showing code; you are showing *systems*.

• Architecture Diagrams: Use a tool like Draw.io to create a flowchart showing how GitHub, Docker, and AWS interact in your workflow. Include this prominently in your repository's README.md.

• The "Why": Explain your architectural decisions. "I chose to use OIDC authentication rather than storing AWS IAM keys as secrets to eliminate the risk of long-lived credential leakage."

• Failure Handling: Explicitly document how your pipeline behaves when a test fails. A pipeline that only handles success is incomplete.

9. Summary #

In Chapter 19, we transitioned from learners to practitioners. We designed five capstone projects that synthesize the entire DevOps lifecycle. From basic CI/CD quality gates to advanced Kubernetes deployments and Infrastructure as Code orchestration, these projects demand the practical application of declarative YAML, secure secret management, and automated testing. By executing these projects and documenting the architectural decisions behind them, you construct a professional portfolio that undeniably proves your engineering capability.

10. Next Chapter Recommendation #

Your portfolio is built, and your skills are validated. It is time to prepare for the technical screening and plan your career trajectory. Proceed to the final chapter: Chapter 20: GitHub Actions Interview Questions and Career Roadmap.