Fluid Forge
Why Forge
Concepts
Get Started
  • Consume a Data Product
  • See it run
  • Demos
  • Local (DuckDB)
  • Source-Aligned (Postgres → DuckDB)
  • AI Forge + Data Models
  • MCP Output Port — Serve to AI Agents
  • GCP (BigQuery)
  • Snowflake Team Collaboration
  • Declarative Airflow
  • Orchestration Export
  • Jenkins CI/CD
  • Universal Pipeline
  • 11-Stage Production Pipeline
  • Catalog Forge End-to-End
CLI Reference
  • Agent Policy (concept)
  • MCP Output Port — Serve to Agents
  • MCP deep-dive
  • AI-assisted authoring
  • LLM providers & backends
  • Overview
  • Quickstart
  • Examples
  • Your own CI
  • Your own scaffolding
  • Custom validator
  • Apply hook
  • Reference
  • Overview
  • Architecture
  • GCP (BigQuery)
  • AWS (S3 + Athena)
  • Snowflake
  • Local (DuckDB)
  • Custom Providers
  • Roadmap
GitHub
Why Forge
Concepts
Get Started
  • Consume a Data Product
  • See it run
  • Demos
  • Local (DuckDB)
  • Source-Aligned (Postgres → DuckDB)
  • AI Forge + Data Models
  • MCP Output Port — Serve to AI Agents
  • GCP (BigQuery)
  • Snowflake Team Collaboration
  • Declarative Airflow
  • Orchestration Export
  • Jenkins CI/CD
  • Universal Pipeline
  • 11-Stage Production Pipeline
  • Catalog Forge End-to-End
CLI Reference
  • Agent Policy (concept)
  • MCP Output Port — Serve to Agents
  • MCP deep-dive
  • AI-assisted authoring
  • LLM providers & backends
  • Overview
  • Quickstart
  • Examples
  • Your own CI
  • Your own scaffolding
  • Custom validator
  • Apply hook
  • Reference
  • Overview
  • Architecture
  • GCP (BigQuery)
  • AWS (S3 + Athena)
  • Snowflake
  • Local (DuckDB)
  • Custom Providers
  • Roadmap
GitHub
  • Introduction

    • Home
    • Why Fluid Forge
    • Getting Started
    • Snowflake Quickstart
    • See it run
    • Forge Data Model
    • Vision & Roadmap
    • Playground
    • FAQ
  • Concepts

    • Concepts
    • Builds, Exposes, Bindings
    • What is a contract?
    • Quality, SLAs & Lineage
    • Governance & Policy
    • Agent Policy (LLM/AI governance)
    • Providers vs Platforms
    • Fluid Forge vs alternatives
  • Data Products

    • Consume a Data Product
    • Product Types — SDP, ADP, CDP
  • Walkthroughs

    • Walkthrough: Local Development
    • Source-Aligned: Postgres → DuckDB → Parquet
    • AI Forge And Data-Model Journeys
    • Walkthrough: MCP Output Port
    • Walkthrough: Deploy to Google Cloud Platform
    • Walkthrough: Snowflake Team Collaboration
    • Declarative Airflow DAG Generation - The FLUID Way
    • Generating Orchestration Code from Contracts
    • Jenkins CI/CD for FLUID Data Products
    • Universal Pipeline
    • The 11-Stage Pipeline
    • End-to-End Walkthrough: Catalog → Contract → Transformation
  • CLI Reference

    • CLI Reference
    • Core workflow

      • fluid init
      • fluid demo
      • fluid forge
      • fluid validate
      • fluid plan
      • fluid apply
      • fluid diff
      • fluid status
    • Build & ship

      • fluid bundle
      • fluid generate
      • fluid generate artifacts
      • fluid validate-artifacts
      • fluid verify-signature
      • fluid generate iac
      • fluid generate-airflow
      • fluid generate-pipeline
      • fluid viz-graph
      • fluid publish
      • fluid ship
      • fluid rollback
      • fluid schedule-sync
    • AI & Agents

      • fluid ai
      • fluid agents
      • fluid mcp
      • fluid memory
      • fluid stats
      • fluid skills
    • Quality & governance

      • fluid test
      • fluid verify
      • fluid contract-tests
      • fluid contract-validation
      • fluid policy
      • fluid policy check
      • fluid policy compile
      • fluid policy apply
    • Standards & interoperability

      • fluid odps
      • fluid odps-bitol
      • fluid odcs
      • fluid export
      • fluid export-odps
      • fluid exporters
      • fluid import
      • fluid market
      • fluid datamesh-manager
    • Project & workspace

      • fluid product-new
      • fluid product-add
      • fluid workspace
      • fluid contract
      • fluid split
      • fluid config
      • fluid providers
      • fluid plugins
      • fluid provider-init
      • fluid auth
      • fluid secrets
      • fluid ide
      • fluid scaffold-ci
      • fluid scaffold-composer
      • fluid scaffold-ide
      • fluid docs
      • fluid runs
      • fluid retention
      • fluid describe
      • fluid doctor
      • fluid roadmap
      • fluid version
    • Catalog adapters

      • Source Catalog Integration (V1.5)
      • Publishing to a Catalog — Overview
      • BigQuery Catalog
      • Snowflake Horizon Catalog
      • Databricks Unity Catalog
      • Google Dataplex Catalog
      • AWS Glue Data Catalog
      • DataHub Catalog
      • Data Mesh Manager Catalog
      • OpenMetadata Catalog
    • CLI by task

      • CLI by task
      • Add quality rules
      • Add agent governance
      • Debug a failed pipeline run
      • Switch clouds with one line
  • Recipes

    • Recipes
    • Recipe — add a quality rule
    • Recipe — switch clouds with one line
    • Recipe — tag PII in your schema
    • Write a contract that consumes another contract
    • Generate per-environment overlays
  • SDK & Plugins

    • SDK & Plugins
    • Quickstart — your first plugin
    • Examples

      • Runnable examples
      • Example: hello-scaffold — the minimal viable plugin
      • Example: gitlab-ci-scaffold — generate a complete CI project
      • Example: steward-validator — a custom governance rule
      • Example: prod-key-guard — apply-time invariant check
    • Journeys

      • Journeys
      • Your own CI/CD

        • You have your own CI/CD setup, no problem
        • GitLab CI — the bundle template
        • GitHub Actions — the bundle template
        • Jenkins — the bundle template
        • CircleCI — the bundle template
      • You have a strict project layout, no problem
      • You have governance rules, no problem
      • You want a check at apply time, no problem
    • Reference

      • Reference
      • Roles reference
      • Entry points reference
      • Trust model
      • Packaging
      • Companion packages
  • Providers

    • Providers
    • Provider Architecture
    • GCP Provider
    • AWS Provider
    • Snowflake Provider
    • Local Provider
    • Creating Custom Providers
    • Provider Roadmap
  • AI & Agents

    • MCP Server
    • Built-in And Custom Forge Guidance
    • Forge Discovery Guide
    • Forge Memory Guide
    • Authoring Forge Tools
    • Guided fluid forge UX
    • LLM Providers
    • LiteLLM Backend
    • Capability Warnings
    • Cost Tracking
    • FLUID Forge Contract GPT Packet
    • Agentic Primitives
  • Operate & Deploy

    • Airflow Integration
    • Blueprints
    • Source-Aligned Acquisition
  • Govern & Secure

    • Governance, Compliance & the Business Case
    • Governance & Compliance
    • Network Safety
    • Credential Resolver — Security Model
  • Configuration & Reference

    • Environment Variables
    • Typed Errors
    • Typed CLI Errors
    • API Stability — fluid_build.api
  • Architecture & Releases

    • V1.5 Catalog Integration — Architecture Deep-Dive
    • V1.5 + V2 Hardening — Release Notes
  • Project

    • Contributing to Fluid Forge
    • Fluid Forge Docs Baseline: CLI 0.9.0
    • Fluid Forge Docs Baseline: CLI 0.8.11
    • Fluid Forge Docs Baseline: CLI 0.8.10
    • Fluid Forge Docs Baseline: CLI 0.8.9
    • Fluid Forge Docs Baseline: CLI 0.8.8
    • Fluid Forge Docs Baseline: CLI 0.8.7
    • Fluid Forge Docs Baseline: CLI 0.8.6
    • Fluid Forge Docs Baseline: CLI 0.8.5
    • Fluid Forge Docs Baseline: CLI 0.8.4
    • Fluid Forge Docs Baseline: CLI 0.8.3
    • Fluid Forge Docs Baseline: CLI 0.8.0
    • Fluid Forge Docs Baseline: CLI 0.7.11
    • Fluid Forge Docs Baseline: CLI 0.7.9
    • Fluid Forge v0.7.1 - Multi-Provider Export Release

Jenkins CI/CD for FLUID Data Products

This walkthrough demonstrates how to implement end-to-end CI/CD for declarative data products using Jenkins and the FLUID framework.

Compatibility note

The contracts and pipeline output shown on this page reference FLUID schema 0.7.1. The CLI validates each contract against its own declared version, so these examples remain valid. For new contracts, prefer the current 0.7.2 shape — run fluid init my-project --quickstart to scaffold one, and use fluid generate ci --system jenkins to regenerate a matching Jenkinsfile.

📋 Overview

The Jenkins pipeline automates the complete lifecycle of a data product:

  1. Contract Validation - Validate FLUID contract schema
  2. Static Analysis - Check governance policies and best practices
  3. Deployment Planning - Generate execution plan without applying changes
  4. Testing - Run dbt tests and data quality checks
  5. Deployment - Apply contract and create/update resources
  6. Verification - Validate deployment and data quality

🎯 Benefits of Declarative CI/CD

Traditional Approach (Imperative)

stage('Deploy') {
    sh 'bq mk dataset'
    sh 'bq load ...'
    sh 'dbt run'
    sh 'python update_metadata.py'
}

Problems:

  • ❌ Manual resource creation
  • ❌ No validation before deployment
  • ❌ Hard to rollback
  • ❌ No infrastructure drift detection

FLUID Approach (Declarative)

stage('Deploy') {
    sh 'fluid validate contract.fluid.yaml'
    sh 'fluid plan contract.fluid.yaml'
    sh 'fluid apply contract.fluid.yaml'
    sh 'fluid verify contract.fluid.yaml'
}

Benefits:

  • ✅ Single source of truth (contract)
  • ✅ Automatic validation
  • ✅ Plan before apply (like Terraform)
  • ✅ Drift detection via verify

🏗️ Pipeline Architecture

┌─────────────────────────────────────────────────────────────┐
│                    Source Control (Git)                      │
│              contract.fluid.yaml + dbt models                │
└──────────────────────┬──────────────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────────────┐
│                   Jenkins Pipeline                           │
├─────────────────────────────────────────────────────────────┤
│  1. Setup          │ Install dependencies, verify env        │
│  2. Validate       │ fluid validate contract.fluid.yaml      │
│  3. Static Analysis│ Check policies, governance metadata     │
│  4. Plan           │ fluid plan (preview changes)            │
│  5. Test           │ dbt test + data quality checks          │
│  6. Deploy         │ dbt run + bq updates (labels)           │
│  7. Verify         │ fluid verify (check compliance)         │
└──────────────────────┬──────────────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────────────┐
│              Google Cloud Platform (BigQuery)                │
│  • Tables: bitcoin_prices                                    │
│  • Views: daily_price_summary, price_trends                  │
│  • Labels: cost-center, environment, sla-tier                │
└─────────────────────────────────────────────────────────────┘

📂 Project Structure

bitcoin-tracker/
├── Jenkinsfile                 # Pipeline definition
├── contract.fluid.yaml         # Data product contract
├── load_bitcoin_price_batch.py # Data ingestion script
├── dbt/
│   ├── dbt_project.yml
│   ├── profiles.yml
│   └── models/
│       ├── daily_price_summary.sql
│       ├── price_trends.sql
│       └── schema.yml
└── runtime/                    # Generated artifacts
    ├── plan.json
    ├── validation-report.json
    └── test-results.json

🚀 Getting Started

1. Jenkins Setup

Prerequisites:

  • Jenkins 2.x or later
  • Plugins:
    • Pipeline
    • Git
    • Google Cloud SDK
    • Credentials Binding

Configure Jenkins:

// In Jenkins System Configuration

// 1. Add GCP credentials
Credentials → Add Credentials
  Kind: Google Service Account from private key
  Project Name: fluid-crypto-tracker
  ID: gcp-data-product-deployer

// 2. Configure tools
Global Tool Configuration
  Python: Python 3.10+
  Git: Latest

2. Create Jenkins Pipeline

Option A: Pipeline from SCM

// In Jenkins Job Configuration
Pipeline → Definition → Pipeline script from SCM
  SCM: Git
  Repository URL: https://github.com/your-org/fluid-mono.git
  Script Path: forge_docs/examples/bitcoin-tracker/Jenkinsfile

Option B: Inline Pipeline

// Copy Jenkinsfile content directly into Jenkins job

3. Configure GCP Authentication

Service Account Method (Recommended for Production):

# 1. Create service account
gcloud iam service-accounts create fluid-cicd \
  --display-name="FLUID CI/CD Service Account" \
  --project=fluid-crypto-tracker

# 2. Grant permissions
gcloud projects add-iam-policy-binding fluid-crypto-tracker \
  --member="serviceAccount:fluid-cicd@fluid-crypto-tracker.iam.gserviceaccount.com" \
  --role="roles/bigquery.admin"

# 3. Create key
gcloud iam service-accounts keys create ~/fluid-cicd-key.json \
  --iam-account=fluid-cicd@fluid-crypto-tracker.iam.gserviceaccount.com

# 4. Add to Jenkins credentials
# Upload fluid-cicd-key.json as "Secret file" credential

OAuth Method (Development):

# In Jenkins agent, authenticate with:
gcloud auth application-default login

4. Set Environment Variables

In Jenkins job configuration:

environment {
    GCP_PROJECT_ID = 'fluid-crypto-tracker'
    GOOGLE_APPLICATION_CREDENTIALS = credentials('gcp-data-product-deployer')
}

📋 Pipeline Stages Explained

Stage 1: Setup Environment

Purpose: Install dependencies and verify prerequisites

stage('Setup Environment') {
    steps {
        sh '''
            # Install Python packages
            pip install dbt-core dbt-bigquery google-cloud-bigquery
            
            # Verify contract file exists
            test -f contract.fluid.yaml
            
            # Test GCP access
            bq ls --project_id=${GCP_PROJECT_ID}
        '''
    }
}

Key Checks:

  • ✅ Python dependencies installed
  • ✅ Contract file exists
  • ✅ GCP credentials valid
  • ✅ BigQuery access confirmed

Stage 2: Validate Contract

Purpose: Ensure contract is syntactically correct and schema-compliant

stage('Validate Contract') {
    steps {
        sh '''
            python3 -m fluid_build.cli validate contract.fluid.yaml
        '''
    }
}

What's Validated:

  • YAML syntax correctness
  • FLUID 0.7.1 schema compliance
  • Required fields present
  • Data types valid
  • References consistent

Sample Output:

Starting validate_contract
Metric: validation_duration=0.042seconds
Metric: validation_errors=0count
Metric: validation_warnings=0count
✅ Valid FLUID contract (schema v0.7.1)

Stage 3: Static Analysis

Purpose: Check best practices and governance policies

stage('Static Analysis') {
    steps {
        sh '''
            # Check governance metadata
            python3 check_governance.py
            
            # Verify dbt models exist
            test -f dbt/models/daily_price_summary.sql
        '''
    }
}

Checks Performed:

  1. Governance Metadata:

    • Product-level labels present
    • Owner information defined
    • Cost allocation tags set
  2. Data Policies:

    • Classification defined (Public/Internal/Confidential)
    • Access control policies (readers/writers)
    • Sensitivity markers for PII fields
  3. Dependencies:

    • dbt models exist for declared builds
    • Python scripts exist for ingestion
    • Source tables referenced exist

Example Policy Check:

# Contract validation rules
required_labels = ['cost-center', 'data-classification', 'billing-tag']
required_policies = ['classification', 'authz']

for expose in contract['exposes']:
    if not all(label in expose['labels'] for label in required_labels):
        raise ValidationError(f"Missing required labels in {expose['exposeId']}")

Stage 4: Plan Deployment

Purpose: Preview changes before applying (like terraform plan)

stage('Plan Deployment') {
    steps {
        sh '''
            python3 -m fluid_build.cli plan contract.fluid.yaml
        '''
    }
}

Output:

============================================================
FLUID Execution Plan
============================================================
Total Actions: 6

1. provision_bitcoin_prices_table (provisionDataset)
2. schedule_build_1 (scheduleTask)
3. provision_daily_price_summary (provisionDataset)
...

Benefits:

  • See what will change before deployment
  • Catch configuration errors early
  • Review resource costs
  • Validate access permissions

Stage 5: Run Tests

Purpose: Validate data quality and transformations

stage('Run Tests') {
    when {
        expression { !params.SKIP_TESTS }
    }
    steps {
        sh '''
            # Run dbt tests
            cd dbt && dbt test
            
            # Custom data quality checks
            python3 data_quality_checks.py
        '''
    }
}

dbt Tests:

# dbt/models/schema.yml
models:
  - name: daily_price_summary
    columns:
      - name: date
        tests:
          - not_null
          - unique
      - name: open_price_usd
        tests:
          - not_null
          - positive_value

Custom Quality Checks:

# data_quality_checks.py
checks = [
    {
        'name': 'No NULL prices',
        'query': 'SELECT COUNT(*) FROM bitcoin_prices WHERE price_usd IS NULL',
        'expected': 0
    },
    {
        'name': 'Data freshness',
        'query': '''
            SELECT TIMESTAMP_DIFF(CURRENT_TIMESTAMP(), MAX(price_timestamp), HOUR)
            FROM bitcoin_prices
        ''',
        'threshold': 24  # Data should be < 24 hours old
    }
]

Stage 6: Deploy

Purpose: Apply contract and create/update resources

stage('Deploy') {
    when {
        expression { !params.DRY_RUN }
    }
    steps {
        // Production requires manual approval
        input message: 'Deploy to Production?'
        
        sh '''
            # Run dbt models
            cd dbt && dbt run
            
            # Apply labels
            bq update --set_label environment:${ENVIRONMENT} \\
                      --set_label cost-center:engineering \\
                      ${GCP_PROJECT_ID}:crypto_data.bitcoin_prices
            
            # Load fresh data
            python3 load_bitcoin_price_batch.py
        '''
    }
}

Key Actions:

  1. Manual Approval (for production)
  2. dbt Execution - Create/update views
  3. Label Application - FinOps tracking
  4. Data Loading - Ingest fresh data

Deployment Safety:

// Require approval for production
if (params.ENVIRONMENT == 'production') {
    input message: 'Deploy to Production?', 
          ok: 'Deploy',
          submitter: 'admin,release-manager'
}

Stage 7: Verify Deployment

Purpose: Validate resources match contract specification

stage('Verify Deployment') {
    steps {
        sh '''
            # Run FLUID verify
            python3 -m fluid_build.cli verify contract.fluid.yaml
            
            # Check labels applied
            bq show --format=json bitcoin_prices | jq '.labels'
            
            # Query sample data
            bq query "SELECT * FROM daily_price_summary LIMIT 1"
        '''
    }
}

Verification Steps:

  1. Schema Compliance - Fields match contract
  2. Data Types - Correct types (FLOAT64, TIMESTAMP, etc.)
  3. Labels - Cost tracking labels applied
  4. Data Quality - Sample queries return valid data
  5. Freshness - Latest data within SLA

Sample Verification Output:

================================================================================
🔍 FLUID Verify - Multi-Dimensional Contract Validation
================================================================================

📋 Verifying: bitcoin_prices_table
   🔍 Dimension 1: Schema Structure
      ✅ PASS - All 8 column names match specification

   🔍 Dimension 2: Data Types
      ✅ PASS - All types match

   🔍 Dimension 3: Constraints
      ✅ PASS - All field constraints match

   🔍 Dimension 4: Location
      ✅ PASS - Region: us-central1

   🔍 Dimension 5: Labels
      ✅ PASS - All required labels present

🎛️ Pipeline Parameters

Configure deployment behavior with parameters:

parameters {
    choice(
        name: 'ENVIRONMENT',
        choices: ['staging', 'production'],
        description: 'Deployment environment'
    )
    booleanParam(
        name: 'DRY_RUN',
        defaultValue: false,
        description: 'Plan only, do not apply'
    )
    booleanParam(
        name: 'SKIP_TESTS',
        defaultValue: false,
        description: 'Skip test execution'
    )
}

Usage:

  • Development: ENVIRONMENT=staging, DRY_RUN=false, SKIP_TESTS=false
  • Production: ENVIRONMENT=production, DRY_RUN=false, SKIP_TESTS=false
  • Preview: Any environment, DRY_RUN=true

📊 Monitoring & Logging

Console Output

The pipeline provides detailed, color-coded output:

═══════════════════════════════════════════════════════════
Stage 2: FLUID Contract Validation
═══════════════════════════════════════════════════════════
🔍 Validating FLUID contract...

✅ Contract validation PASSED
   Contract is compliant with FLUID 0.7.1 schema

📊 Contract Metadata:
  ID: crypto.bitcoin_prices_gcp
  Version: 0.7.1
  Exposes: 3 datasets
  Builds: 3 transformations

Artifacts

The pipeline archives important artifacts:

  • validation-report.json - Contract validation results
  • plan.json - Deployment plan
  • dbt-test-output.log - Test results
  • verify-output.log - Post-deployment verification

Access artifacts:

Jenkins Job → Build #123 → Artifacts → runtime/plan.json

Metrics

Key metrics tracked:

  • Build Duration - Total pipeline execution time
  • Validation Duration - Contract validation time
  • Test Pass Rate - Percentage of tests passing
  • Deployment Success Rate - % of successful deployments

🔒 Security Best Practices

1. Credentials Management

Don't:

// ❌ Never hardcode credentials
environment {
    GCP_KEY = 'AKIA...'  // BAD!
}

Do:

// ✅ Use Jenkins credentials
environment {
    GOOGLE_APPLICATION_CREDENTIALS = credentials('gcp-service-account')
}

2. Least Privilege

# Grant only required permissions
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="serviceAccount:${SA_EMAIL}" \
  --role="roles/bigquery.dataEditor"  # Not bigquery.admin

3. Approval Gates

// Require approval for sensitive operations
if (params.ENVIRONMENT == 'production') {
    input message: 'Proceed with production deployment?',
          submitter: 'release-managers'
}

4. Audit Logging

post {
    always {
        // Log all deployments
        sh '''
            echo "$(date): Deployment to ${ENVIRONMENT} by ${BUILD_USER}" \
                >> /var/log/fluid-deployments.log
        '''
    }
}

🐛 Troubleshooting

Common Issues

1. Contract Validation Fails

Error:

❌ Contract validation FAILED
   Error: Missing required field 'fluidVersion'

Solution:

# Add at top of contract.fluid.yaml
fluidVersion: "0.7.2"
kind: DataProduct

2. GCP Authentication Fails

Error:

ERROR: (gcloud.auth.application-default.login) 
Unable to find Application Default Credentials

Solution:

# In Jenkins, set credential binding
withCredentials([file(credentialsId: 'gcp-key', variable: 'GOOGLE_APPLICATION_CREDENTIALS')]) {
    sh 'gcloud auth activate-service-account --key-file=${GOOGLE_APPLICATION_CREDENTIALS}'
}

3. dbt Tests Fail

Error:

Failure in test not_null_bitcoin_prices_price_usd
  Got 5 results, expected 0

Solution:

-- Fix NULL values in source data
DELETE FROM bitcoin_prices WHERE price_usd IS NULL;

4. Labels Not Applied

Error:

⚠️  Labels: null

Solution:

# FLUID apply currently has issues, use manual bq update:
bq update --set_label cost-center:engineering table_name

📈 Advanced Patterns

Multi-Environment Deployment

pipeline {
    stages {
        stage('Deploy to Staging') {
            environment {
                GCP_PROJECT_ID = 'project-staging'
            }
            steps {
                sh 'fluid apply contract.fluid.yaml'
            }
        }
        
        stage('Smoke Test Staging') {
            steps {
                sh 'python3 smoke_tests.py --env=staging'
            }
        }
        
        stage('Deploy to Production') {
            when {
                branch 'main'
            }
            environment {
                GCP_PROJECT_ID = 'project-production'
            }
            steps {
                input 'Deploy to production?'
                sh 'fluid apply contract.fluid.yaml'
            }
        }
    }
}

Parallel Testing

stage('Tests') {
    parallel {
        stage('Unit Tests') {
            steps {
                sh 'pytest tests/unit'
            }
        }
        stage('dbt Tests') {
            steps {
                sh 'dbt test'
            }
        }
        stage('Data Quality') {
            steps {
                sh 'python3 dq_checks.py'
            }
        }
    }
}

Rollback Support

stage('Deploy') {
    steps {
        script {
            try {
                sh 'fluid apply contract.fluid.yaml'
            } catch (Exception e) {
                echo "Deployment failed, rolling back..."
                sh 'git checkout HEAD~1 contract.fluid.yaml'
                sh 'fluid apply contract.fluid.yaml'
                throw e
            }
        }
    }
}

📚 Related Documentation

  • GCP Deployment Guide
  • Declarative Airflow Integration
  • Getting Started

🎯 Next Steps

  1. Set Up Jenkins Job - Create pipeline using provided Jenkinsfile
  2. Configure GCP Access - Set up service account credentials
  3. Test in Staging - Run pipeline with ENVIRONMENT=staging
  4. Monitor First Deploy - Review logs and artifacts
  5. Automate Triggers - Set up Git webhook for automatic builds
  6. Add Notifications - Configure Slack/email alerts for failures

💡 Best Practices Summary

✅ DO:

  • Use declarative FLUID contracts as single source of truth
  • Validate before deploying (fluid validate → fluid plan → fluid apply)
  • Run tests in CI/CD pipeline
  • Require manual approval for production
  • Archive deployment artifacts
  • Monitor data quality post-deployment

❌ DON'T:

  • Hardcode credentials in pipeline
  • Skip validation or tests for "quick fixes"
  • Deploy directly to production without staging
  • Ignore failed tests in production pipeline
  • Deploy without reviewing the plan

Questions or issues? Open an issue on GitHub.

Edit this page on GitHub
Last Updated: 5/17/26, 6:10 PM
Contributors: Jeff Watson, jeffwatson-ai, fas89, Claude Opus 4.7 (1M context)
Prev
Generating Orchestration Code from Contracts
Next
Universal Pipeline