Module 10 Lesson 2: Modular Pipeline Design

A modular pipeline is one where the "Build logic" is separated from the "Business logic." Just like you write modular code, you should write modular DevOps.

1. The "Big File" Problem

A 1,000-line .gitlab-ci.yml is a liability.

• It's hard to find bugs.
• Merge conflicts happen constantly when 5 teams are all editing the same file.

---

2. The Recommended Structure

Instead of one file, use a folder called .gitlab/ci/:

• /.gitlab/ci/build.yml
• /.gitlab/ci/test.yml
• /.gitlab/ci/deploy-staging.yml
• /.gitlab/ci/deploy-prod.yml

The Main File:

# .gitlab-ci.yml
include:
  - local: .gitlab/ci/build.yml
  - local: .gitlab/ci/test.yml
  - local: .gitlab/ci/deploy-staging.yml
  - local: .gitlab/ci/deploy-prod.yml

---

3. Designing for Autonomy

In this model, the "Mobile Team" only owns the .gitlab/ci/ios.yml file. They can change their build flags without ever talking to the "Backend Team." This Decoupling is the secret to moving fast at scale.

---

4. Reusable "Stage-less" Jobs

Avoid putting stage: build inside your modules. Put it in the Master file.

• Why?: This allows you to use the same "Lint Module" in the test stage for one project, and in the pre-build stage for another.

---

Exercise: The Modular Refactor

1. Take your most complex .gitlab-ci.yml from this course.
2. Create a .gitlab/ci/ directory.
3. Split the jobs into at least 3 separate files based on their function.
4. Update the main file to use include:local.
5. Run the Pipeline Editor Visualization (Module 2). Does it look exactly the same as before? (If so, you succeeded!).
6. Why is this structure better for someone reading your code for the first time?

---

Summary

Modular Design is the hallmark of a Senior DevOps Engineer. By breaking your monolithic configuration into smaller, functional pieces, you create a system that is easier to debug, safer to update, and more welcoming to your fellow developers.

Next Lesson: Naming matters: Variable Naming and Scoping.