Capstone Part 2: Building the Pipeline

In Part 2, we translate our "Architecture Map" into a working .gitlab-ci.yml. We will focus on the Build and Test phases for our Backend and Frontend services.

1. Defining the Global Config

stages:
  - lint
  - build
  - test
  - deploy

variables:
  BACKEND_IMAGE: "$CI_REGISTRY_IMAGE/backend:$CI_COMMIT_REF_SLUG"
  FRONTEND_IMAGE: "$CI_REGISTRY_IMAGE/frontend:$CI_COMMIT_REF_SLUG"

# Global Cache for Node modules
cache:
  key: "$CI_COMMIT_REF_SLUG"
  paths: [node_modules/]

2. The Lint Stage (Speed First)

lint-backend:
  stage: lint
  image: node:18-alpine
  script:
    - npm ci
    - npm run lint

3. Parallel Docker Builds (Efficiency)

Instead of building one-by-one, we use Kaniko in a parallel job.

.build_template: &build_def
  image: 
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: [""]
  stage: build

build-backend:
  <<: *build_def
  script:
    - /kaniko/executor --context $CI_PROJECT_DIR/backend --destination $BACKEND_IMAGE

build-frontend:
  <<: *build_def
  script:
    - /kaniko/executor --context $CI_PROJECT_DIR/frontend --destination $FRONTEND_IMAGE

4. Why Use a Template?

In the code above, we used an Anchor (&build_def). If the team decides to add a new service (e.g., "Mobile-API"), you can add it in 3 lines of code by extending this parent. This follows the DRY Principle (Module 10).

Exercise: The Builder's Challenge

Implement the test-backend job. It must use a postgres:alpine service (Module 5) and run npm run test:integration.
Why is it important to use npm ci instead of npm install in the lint stage? (Review Module 11).
If build-backend fails, will build-frontend still finish? (Why?)
Modify the variables block to include a VERSION tag based on the $CI_COMMIT_SHORT_SHA.

Summary

You have built the "skeleton" of the GlobalHealth Connect pipeline. By using anchors and parallel builds, you have created a foundation that is fast and easy to scale.

Next Lesson: Part 3: Integrating Security and Quality Gates.