Platform Integration Patterns

AEEF standards are CI/CD-platform-agnostic. This guide provides integration patterns for organizations using GitLab CI/CD, Azure DevOps, Bitbucket Pipelines, or hybrid environments alongside the GitHub Actions examples in the CI/CD Pipeline Starter.

Platform Comparison Matrix

Capability	GitHub Actions	GitLab CI/CD	Azure DevOps	Bitbucket Pipelines
SAST integration	Native (CodeQL) + third-party actions	SAST templates, Semgrep	Microsoft Security DevOps task	Third-party pipes
SCA / dependency scanning	Dependabot, third-party actions	Dependency Scanning template	Component Governance	Snyk pipe
Secrets scanning	Secret scanning (native)	Secret Detection template	Credential Scanner task	Third-party pipes
Quality gates	Branch protection + status checks	Merge request approval rules	Branch policies + gates	Merge checks
Approval workflows	CODEOWNERS + required reviews	Approval rules + CODEOWNERS	Pull request policies	Default reviewers + merge checks
Artifact management	GitHub Packages	GitLab Package Registry / Container Registry	Azure Artifacts	Bitbucket Downloads (limited)
Environment protection	Environment protection rules	Protected environments	Release gates + approvals	Deployment permissions

Platform-Agnostic Governance Patterns

Regardless of platform, implement these patterns:

Pattern 1: Gate-Before-Merge

Every merge request / pull request SHOULD pass automated gates before human review is allowed to proceed.

Gate sequence:

Lint → Build → Unit tests → SAST → SCA → Secrets scan → Coverage check → Quality gate verdict

• Gates SHOULD run in parallel where possible to minimize pipeline duration
• Gate failure SHOULD block merge (not just warn)
• Gate results SHOULD be visible as status checks on the merge/pull request

Pattern 2: Environment Promotion

Code progresses through environments with increasing governance controls.

Development → Staging → Pre-production → Production

Environment	Automated Gates	Manual Approval	Monitoring
Development	Lint, unit tests	None	Basic
Staging	Full gate suite	None	Standard
Pre-production	Full gate suite + integration tests	Required for Tier 2/3	Enhanced
Production	Canary deployment gates	Required for Tier 2/3	Full observability

Pattern 3: Policy-as-Code

Governance policies SHOULD be expressed as code and version-controlled alongside application code.

• Security policies (allowed/blocked dependencies, vulnerability thresholds)
• Review policies (required reviewers, CODEOWNERS)
• Deployment policies (environment promotion rules, rollback criteria)
• Cost policies (compute budget limits, inference cost thresholds)

Pattern 4: Audit Trail Automation

Every pipeline run SHOULD produce audit artifacts:

• Gate results with pass/fail status and evidence
• Reviewer identity and approval timestamp
• Artifact checksums and provenance metadata
• Deployment target, timestamp, and deployer identity

GitLab CI/CD Integration

Quality Gates Configuration

# .gitlab-ci.yml - AEEF quality gates
stages:
  - lint
  - test
  - security
  - quality-gate
  - deploy

variables:
  COVERAGE_THRESHOLD: "80"

lint:
  stage: lint
  script:
    - npm run lint
  rules:
    - if: $CI_MERGE_REQUEST_IID

unit-tests:
  stage: test
  script:
    - npm run test -- --coverage
  coverage: '/All files[^|]*\|[^|]*\s+([\d\.]+)/'
  artifacts:
    reports:
      junit: reports/junit.xml
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml

sast:
  stage: security
  template: Security/SAST.gitlab-ci.yml

dependency-scanning:
  stage: security
  template: Security/Dependency-Scanning.gitlab-ci.yml

secret-detection:
  stage: security
  template: Security/Secret-Detection.gitlab-ci.yml

quality-gate:
  stage: quality-gate
  script:
    - |
      if [ "$CI_MERGE_REQUEST_APPROVED" != "true" ]; then
        echo "Merge request not yet approved"
        exit 1
      fi
    - echo "All quality gates passed"
  rules:
    - if: $CI_MERGE_REQUEST_IID

Merge Request Approval Rules

Configure in GitLab project settings:

• Required approvals: Minimum 1 (Tier 1), 2 (Tier 2/3)
• CODEOWNERS approval: Required for files matching CODEOWNERS patterns
• Security approval: Required when security scan finds new vulnerabilities
• All pipelines must succeed: Enabled

Protected Environments

# Production deployment with manual approval
deploy-production:
  stage: deploy
  environment:
    name: production
  script:
    - ./deploy.sh production
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual

Configure protected environments in GitLab to require approval from designated deployers.

Azure DevOps Integration

Pipeline Configuration

# azure-pipelines.yml - AEEF quality gates
trigger:
  branches:
    include:
      - main

pr:
  branches:
    include:
      - main

stages:
  - stage: QualityGates
    displayName: 'AEEF Quality Gates'
    jobs:
      - job: LintAndTest
        displayName: 'Lint, Test & Coverage'
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - task: NodeTool@0
            inputs:
              versionSpec: '20.x'

          - script: npm ci
            displayName: 'Install dependencies'

          - script: npm run lint
            displayName: 'Lint'

          - script: npm run test -- --coverage --ci
            displayName: 'Unit tests with coverage'

          - task: PublishTestResults@2
            inputs:
              testResultsFormat: 'JUnit'
              testResultsFiles: '**/junit.xml'

          - task: PublishCodeCoverageResults@2
            inputs:
              summaryFileLocation: 'coverage/cobertura-coverage.xml'

      - job: SecurityScan
        displayName: 'Security Scanning'
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - task: MicrosoftSecurityDevOps@1
            displayName: 'Microsoft Security DevOps'

  - stage: Deploy
    displayName: 'Deploy to Production'
    dependsOn: QualityGates
    condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
    jobs:
      - deployment: Production
        displayName: 'Production Deployment'
        environment: 'production'
        strategy:
          runOnce:
            deploy:
              steps:
                - script: ./deploy.sh production
                  displayName: 'Deploy'

Branch Policies

Configure in Azure DevOps project settings:

• Require minimum number of reviewers: 1 (Tier 1), 2 (Tier 2/3)
• Check for linked work items: Recommended
• Check for comment resolution: Required
• Build validation: Add the quality gates pipeline as a build policy
• Automatically included reviewers: Add security team for security-sensitive paths

Release Gates

For production deployments, configure release gates:

• Pre-deployment gates: Query work items, invoke REST API for deployment approval
• Post-deployment gates: Query Azure Monitor alerts, check health endpoint

Bitbucket Pipelines Integration

Pipeline Configuration

# bitbucket-pipelines.yml - AEEF quality gates
image: node:20

definitions:
  steps:
    - step: &lint
        name: Lint
        caches:
          - node
        script:
          - npm ci
          - npm run lint

    - step: &test
        name: Test with Coverage
        caches:
          - node
        script:
          - npm ci
          - npm run test -- --coverage --ci
        artifacts:
          - coverage/**

    - step: &security
        name: Security Scan
        script:
          - pipe: snyk/snyk-scan:1.0.0
            variables:
              SNYK_TOKEN: $SNYK_TOKEN
              LANGUAGE: "node"

pipelines:
  pull-requests:
    '**':
      - parallel:
          - step: *lint
          - step: *test
          - step: *security

  branches:
    main:
      - parallel:
          - step: *lint
          - step: *test
          - step: *security
      - step:
          name: Deploy to Production
          deployment: production
          trigger: manual
          script:
            - ./deploy.sh production

Merge Checks

Configure in Bitbucket repository settings:

• Minimum approvals: 1 (Tier 1), 2 (Tier 2/3)
• Default reviewers: Add team leads and security reviewers
• Merge checks: Require passing builds, no unresolved merge conflicts
• Deployment permissions: Restrict production deployment to designated deployers

Hybrid and Multi-Platform Environments

Organizations using multiple CI/CD platforms SHOULD:

1. Standardize gate definitions — define quality gates in a platform-agnostic format (e.g., a shared configuration file) and translate to platform-specific syntax
2. Centralize security scanning — use a single security scanning tool suite across all platforms for consistent results
3. Unify audit trails — aggregate pipeline results into a single audit system regardless of originating platform
4. Consistent approval workflows — enforce the same approval requirements across platforms using CODEOWNERS or equivalent

Shared Gate Definition Example

# aeef-gates.yaml - Platform-agnostic gate definitions
gates:
  lint:
    required: true
    blocking: true

  unit-tests:
    required: true
    blocking: true
    coverage_threshold: 80

  sast:
    required: true
    blocking: true
    severity_threshold: high

  sca:
    required: true
    blocking: true
    severity_threshold: critical

  secrets-scan:
    required: true
    blocking: true

  review:
    required: true
    min_approvers: 1
    codeowners_required: true

Each platform adapter reads this file and enforces the gates using platform-native mechanisms.

Cross-References

• CI/CD Pipeline Starter
• PRD-STD-004: Security Scanning
• PRD-STD-007: Performance & Quality Gates
• PRD-STD-008: Dependency & License Compliance
• PRD-STD-002: Code Review Standards