Skip to main content
Continuous Integration
CHAPTER 06

Automated Builds and Pipelines

Updated: May 15, 2026
25 min read

# CHAPTER 6

Automated Builds and Pipelines

1. Introduction

Downloading code onto a CI runner is easy; making that code actually run is the challenge. Modern applications are not just a collection of text files. They require dependencies (libraries), compilation (turning code into machine language), and asset minification (shrinking CSS/JS files). The process of assembling all these pieces into a final, runnable application is called The Build. In this chapter, we will architect a multi-stage CI pipeline that automates the build process and securely stores the final, compiled application as a downloadable Artifact.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Define the "Build Phase" of a CI/CD pipeline.
  • Understand dependency management in automated workflows (e.g., Composer, NPM).
  • Structure a pipeline into logical execution Stages.
  • Define what a Build Artifact is and why it matters.
  • Use GitHub Actions to upload and store Artifacts.

3. Beginner-Friendly Explanation

Imagine building a custom bicycle.
  • The Code (Git): The blueprints for the bike.
  • Dependencies: Buying the wheels, the chain, and the gears from a supplier.
  • The Build Phase: Actually bolting the wheels to the frame, painting the bike, and pumping the tires.
  • The Artifact: The fully assembled, ready-to-ride bicycle.

You don't want to send a customer blueprints and a box of gears. You want to send them the Artifact. A CI pipeline does the bolting, painting, and pumping automatically.

4. The Build Phase Architecture

Regardless of the programming language, a Build pipeline usually follows three distinct steps:
  1. 1. Setup Environment: Install the correct version of PHP, Node.js, or Java on the CI Runner.
  1. 2. Install Dependencies: Run the package manager command (e.g., composer install for PHP, npm install for Node, mvn clean install for Java).
  1. 3. Compile / Assemble: Run the build script (e.g., npm run build to minify CSS, or go build to create a binary executable).

5. What is a Build Artifact?

When a CI pipeline finishes running, the temporary cloud server (the Runner) is instantly destroyed. If the Runner spent 10 minutes compiling a massive application, that compiled application is deleted too! To save the application so we can deploy it later, we must extract it from the Runner before it dies. We call this packaged, final product an Artifact (usually a .zip file, a .tar.gz, or a Docker Image).

6. Mini Project: Build CI Pipeline for PHP App

Let's build a GitHub Actions workflow that installs PHP dependencies using Composer, packages the final application, and saves it as an Artifact.

Step-by-Step Architecture Concept:

yaml
123456789101112131415161718192021222324252627282930313233 
name: PHP Build Pipeline

on:
  push:
    branches: [ "main" ]

jobs:
  build:
    runs-on: ubuntu-latest

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

      - name: Setup PHP Environment
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.1'

      # The Build Step!
      - name: Install Composer Dependencies
        run: composer install --no-dev --optimize-autoloader

      # Package the files into a single zip archive
      - name: Create Build Archive
        run: zip -r release.zip . -x "*.git*"

      # Extract the Artifact before the runner is destroyed!
      - name: Upload Build Artifact
        uses: actions/upload-artifact@v4
        with:
          name: php-app-release # The name of the artifact
          path: release.zip     # The file to save

*When this pipeline finishes, you can go to the "Actions" tab in GitHub and physically download release.zip. This is your production-ready artifact!*

7. Real-World Scenarios

A development team used to build their React application locally on their laptops. Developer A was using Node.js version 14. Developer B was using Node.js version 18. When Developer A compiled the code, it worked. When Developer B compiled it, it broke. They spent hours arguing over whose computer was right. The DevOps team implemented a centralized CI Build Pipeline. The pipeline strictly defined node-version: '16'. Now, the build was "Deterministic." It didn't matter what the developers had on their laptops; the official production build was always executed in the exact same environment by the CI robot, eliminating the "It works on my machine" problem permanently.

8. Best Practices

  • Exclude Dev Dependencies: When running the build phase for a production application, you should never install "dev dependencies" (like testing frameworks or debugging tools). They bloat the artifact size and introduce security vulnerabilities. Notice in our mini-project we used composer install --no-dev. This ensures the final artifact contains ONLY the code required to run the app.

9. Security Recommendations

  • Immutable Artifacts: Once an artifact is built and given a version number (e.g., v1.0.5), it must never be changed. If you need to fix a bug, you don't open the release.zip and edit the file. You fix the code in Git, push it, and let the CI pipeline generate a brand new artifact (v1.0.6). This ensures absolute traceability.

10. Troubleshooting Tips

  • Missing Files in Artifact: If you use actions/upload-artifact but the resulting zip file is missing directories, check the path: variable. If you specify path: src/, the artifact will ONLY contain the src folder. If you need the entire project, specify path: . (the current directory) or zip the files manually before uploading, as demonstrated in the project.

11. Exercises

  1. 1. What is the operational purpose of a "Build Artifact" in a CI/CD pipeline?
  1. 2. Explain why installing dependencies (like running npm install) must occur *before* the build/compilation phase.

12. FAQs

Q: Where are artifacts stored? A: In GitHub Actions, they are stored directly on GitHub's servers (attached to the specific workflow run). In enterprise architectures, artifacts are often pushed to dedicated artifact repositories like JFrog Artifactory or AWS S3.

13. Interview Questions

  • Q: Describe the lifecycle of a CI pipeline from Code Checkout to Artifact Generation. Why is it critical to extract the artifact from the CI runner before the pipeline completes?
  • Q: Explain the concept of "Deterministic Builds." How does utilizing a centralized CI pipeline resolve the "It works on my machine" discrepancy among developers?

14. Summary

In Chapter 6, we transformed raw code into a functional, deployable product. We established the standard architecture of the Build Phase, ensuring our pipeline provisions the correct environment and securely resolves third-party dependencies. Most importantly, we solved the ephemeral nature of CI runners by introducing Build Artifacts. By packaging our compiled application into a .zip archive and uploading it utilizing GitHub Actions, we successfully extracted a permanent, version-controlled, production-ready asset from a temporary cloud server.

15. Next Chapter Recommendation

We have built the application, but how do we know it actually works? A pipeline that builds broken code is useless. Proceed to Chapter 7: Automated Testing Fundamentals.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Previous Chapter GitHub Actions for Continuous Integration
Next Chapter Code Quality and Static Analysis

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·

Explore More

📖 Related Tutorials 4

❓ Related Quizzes 5