Module 5 Lesson 5: Implementing Quality Gates

A Quality Gate is a set of conditions that MUST be met before a piece of code can move forward. It is the "Police Officer" of your repository.

1. Gate 1: Merge Request Dependencies

In GitLab, you can set a rule that: "Merging is blocked until the pipeline finishes AND is green."

• This ensures that no "Broken" code ever touches your main branch.

---

2. Gate 2: The Coverage Floor

You can set a rule that fails the build if code coverage drops below a certain level (e.g., 80%).

test-coverage-check:
  stage: test
  script:
    - check-coverage-script.sh --min 80

• This forces developers to write tests for their new features before they can merge.

---

3. Gate 3: Approval Rules (The Human Check)

Automation is great, but some things need a person.

• Security Approval: Any changes to the auth/ folder must be approved by the "Security Team."
• Architecture Approval: Any change to docker-compose.yml needs a "Senior Engineer" to look at it.

---

4. Gate 4: Security Criticals

You can configure GitLab to fail a merge if the SAST scan (Lesson 4) finds a "Critical" or "High" vulnerability.

• The Policy: "We don't ship known CVEs."

---

Exercise: The Gates of Truth

1. In your project Settings -> General -> Merge Requests, find the "Merge checks" section.
2. Enable "Pipelines must succeed."
3. Add a "New Test" that intentionally fails. Try to merge your branch to main. Does GitLab let you?
4. Why are "Merge Request Approvals" essential for a large team of 500+ developers?
5. Search: What is the "Toyota Production System" (TPS) and how does the "Andon Cord" relate to Modern Quality Gates?

---

Summary

You have completed Module 5: Testing and Quality Assurance. You have moved from simple "Hello World" scripts to a "Fortified Delivery Machine" that checks code style, logic, security, and standards automatically.

Next Module: Reaching the user: Module 6: Deployment Strategies.