As part of the PantheraHive "DevOps Pipeline Generator" workflow, this deliverable provides comprehensive and detailed CI/CD pipeline configurations for three leading platforms: GitHub Actions, GitLab CI, and Jenkins. These configurations are designed to include essential stages such as linting, testing, building, and deployment, offering a robust foundation for your software delivery process.
This document presents actionable CI/CD pipeline configurations tailored for common development scenarios. Each configuration is structured to be easily adaptable to your specific project needs, technology stack, and deployment targets.
The generated pipelines adhere to the following best practices:
GitHub Actions provides a flexible and powerful way to automate workflows directly within your GitHub repository.
File Location: .github/workflows/main.yml
--- ## 3. Jenkins Declarative Pipeline Configuration Jenkins offers extensive customization and is suitable for complex enterprise environments. This example uses a Declarative Pipeline. **File Location**: `Jenkinsfile` (at the root of your repository)
Welcome to the initial phase of your DevOps Pipeline Generation journey. This crucial first step, "Analyze Infrastructure Needs," lays the foundational groundwork for designing a robust, efficient, and tailored CI/CD pipeline. The objective is to comprehensively assess your current and target technical landscape, identifying all critical components and requirements that will influence the choice of CI/CD tool (GitHub Actions, GitLab CI, or Jenkins), pipeline structure, and deployment strategy.
Without a deep understanding of your infrastructure, application architecture, and operational practices, generating an effective pipeline is challenging. This analysis will guide us in making informed decisions, ensuring the generated pipeline is not only functional but also optimized for your specific environment.
This analysis identifies key areas essential for defining your CI/CD pipeline. These areas encompass Source Code Management (SCM), application technology stack, deployment targets, security, testing, and operational considerations. The goal is to gather detailed insights into your existing ecosystem to recommend the most suitable CI/CD platform and design a pipeline that integrates seamlessly.
Key Findings (General): Modern CI/CD pipelines prioritize automation, security-by-design (shift-left), containerization, and cloud-native integrations. The choice of CI/CD tool often correlates with the chosen SCM and cloud provider.
Initial Recommendation: A detailed inventory of your current infrastructure, application details, and operational preferences is critical for proceeding. The "Next Steps" section outlines the specific information required.
To generate a truly effective CI/CD pipeline, we need to understand the following critical infrastructure components and requirements:
* Platform: GitHub, GitLab, Bitbucket, Azure DevOps, or other.
* Repository Structure: Monorepo vs. polyrepo.
* Branching Strategy: GitFlow, GitHub Flow, GitLab Flow, Trunk-Based Development.
* Permissions & Access Control: How is access managed for repositories and users?
* Programming Languages: Python, Java, Node.js, Go, .NET, Ruby, PHP, C++, etc.
* Frameworks: React, Angular, Spring Boot, Django, Flask, Express, ASP.NET Core, etc.
* Build Tools: Maven, Gradle, npm, yarn, pip, Go Modules, Docker Compose, Kubernetes manifests, Terraform, Ansible.
* Database Technologies: SQL (PostgreSQL, MySQL, SQL Server), NoSQL (MongoDB, Cassandra, DynamoDB).
* Cloud Provider(s): AWS, Azure, GCP, On-premise, Hybrid.
* Target Infrastructure:
* Virtual Machines (VMs): EC2, Azure VMs, GCP Compute Engine, vSphere.
* Container Orchestration: Kubernetes (EKS, AKS, GKE, OpenShift), Docker Swarm.
* Serverless: AWS Lambda, Azure Functions, GCP Cloud Functions/Run.
* Platform as a Service (PaaS): AWS Elastic Beanstalk, Azure App Service, Heroku, GCP App Engine.
* Environment Stages: Dev, Test, Staging, Production.
* Geographic Regions: Multi-region deployments.
kubectl apply, aws deploy, az webapp deploy).* Container Runtime: Docker, containerd.
* Container Registry: Docker Hub, AWS ECR, Azure ACR, GCP GCR, GitLab Container Registry, Quay.io, Artifactory.
* Image Tagging Strategy: Semantic versioning, Git SHA, build number.
* Secrets Management: AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, HashiCorp Vault, Kubernetes Secrets, external CI/CD secrets.
* Vulnerability Scanning: SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing), SCA (Software Composition Analysis), container image scanning (e.g., Trivy, Clair).
* Compliance Standards: HIPAA, GDPR, SOC2, PCI DSS.
* Access Control & Least Privilege: How are pipeline agents authenticated?
* Test Types: Unit tests, integration tests, end-to-end (E2E) tests, performance tests, security tests, UI tests.
* Test Frameworks: Jest, JUnit, Pytest, Selenium, Cypress, Playwright, JMeter.
* Test Reporting: Junit XML, HTML reports.
* Tools: ESLint, Prettier, SonarQube, Black, Flake8, RuboCop, Checkstyle, GoLint.
* Configuration: Custom rule sets, integration with IDEs.
* Artifact Repository: AWS S3, Azure Blob Storage, GCP Cloud Storage, JFrog Artifactory, Sonatype Nexus, GitLab Generic Packages.
* Versioning Strategy: How are artifacts versioned and managed?
* Current CI/CD Tool: If any, what is it? What are its strengths/weaknesses?
* Automation Level: How much is currently automated?
* Team Expertise: Familiarity with specific CI/CD tools, scripting languages, and cloud platforms.
Based on general best practices and the common needs of modern software development, we recommend the following foundational approaches:
To proceed with generating a highly effective and tailored CI/CD pipeline, we require specific details regarding your infrastructure and application. Please provide the following information:
* Which platform do you use (e.g., GitHub.com, GitHub Enterprise, GitLab.com, self-hosted GitLab, Bitbucket Cloud, Azure DevOps Repos)?
* Primary Programming Language(s) & Framework(s): (e.g., Python/Django, Node.js/React, Java/Spring Boot, Go, .NET Core)
* Build Tool(s): (e.g., npm, yarn, Maven, Gradle, pip, make, Docker build)
* Is the application containerized (Docker)? (Yes/No)
* If Yes, which Container Registry do you use (e.g., Docker Hub, AWS ECR, Azure ACR, GitLab Registry)?
* Cloud Provider(s): (e.g., AWS, Azure, GCP, On-premise, Hybrid)
* Specific Deployment Environment(s): (e.g., AWS EKS, AWS EC2, Azure App Service, Azure AKS, GCP Cloud Run, GCP GKE, On-premise VMs, Serverless Functions)
* How do you typically deploy? (e.g., kubectl apply, aws cli, az cli, custom scripts, Ansible, Terraform)
* Do you have a preference among GitHub Actions, GitLab CI, or Jenkins? If so, why?
* Are there specific security scans you require (e.g., SAST, SCA, DAST, Secret Scanning)?
* Are there any specific compliance standards (e.g., HIPAA, GDPR) that need to be addressed?
* Which types of tests are critical for your application (e.g., Unit, Integration, E2E)?
* Do you use specific testing frameworks (e.g., Jest, JUnit, Pytest, Selenium, Cypress)?
* How do you currently manage sensitive
groovy
// Jenkinsfile for a Declarative Pipeline
pipeline {
agent {
docker {
image 'node:20-alpine' // Use a Node.js image for linting/testing
args '-u 1000:1000' // Ensure permissions are correct if running as non-root
}
}
environment {
// Define environment variables accessible across stages
DOCKER_IMAGE_NAME = "your-app-name"
DOCKER_REGISTRY = "your-docker-registry.com/your-org" // e.g., myregistry.com/myorg or public Docker Hub
AWS_REGION = "us-east-1"
}
stages {
stage('Lint Code') {
steps {
script {
echo "Running linting checks..."
sh 'npm ci' // Or yarn install
sh 'npm run lint' // Or yarn lint
echo "Linting complete."
}
}
}
stage('Run Tests') {
steps {
script {
echo "Running unit and integration tests..."
sh 'npm test' // Or yarn test
// Optionally publish test results
// junit '**/test-results.xml'
echo "Tests complete."
}
}
}
stage('Build Docker Image') {
agent {
docker {
image 'docker:latest' // Use a Docker image with Docker CLI
args '-u 1000:1000'
}
}
steps {
script {
echo "Building Docker image..."
// Use withCredentials to inject Docker Hub / ECR credentials securely
withCredentials([usernamePassword(credentialsId: 'docker-hub-credentials', usernameVariable: 'DOCKER_USERNAME', passwordVariable: 'DOCKER_PASSWORD')]) {
sh "docker login -u $DOCKER_USERNAME -p $DOCKER_PASSWORD $DOCKER_REGISTRY"
sh "docker
We are pleased to deliver comprehensive CI/CD pipeline configurations tailored for your project. These configurations provide a robust foundation for automating your software delivery process, integrating best practices for quality assurance, efficient building, and staged deployments.
This deliverable includes detailed, professional-grade pipeline definitions for the three most popular CI/CD platforms: GitHub Actions, GitLab CI, and Jenkins. Each configuration incorporates essential stages: Linting, Testing, Building (Dockerized), and Deployment to multiple environments.
The provided pipeline configurations are designed with the following core principles and features:
Below are the detailed CI/CD pipeline configurations for each platform. Each example assumes a generic web application that is built into a Docker image and deployed.
Filename: .github/workflows/main.yml
This workflow triggers on pushes to the main branch and pull requests, executing linting, testing, and building. Deployment jobs are conditional.
name: CI/CD Pipeline
on:
push:
branches:
- main
pull_request:
branches:
- main
env:
PROJECT_NAME: my-web-app
DOCKER_REGISTRY: ghcr.io/${{ github.repository_owner }}
# Example: For a Node.js app
NODE_VERSION: '18'
jobs:
# Job for linting, testing, and building the Docker image
lint_test_build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
# --- Linting Stage (Example: Node.js/ESLint) ---
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: ${{ env.NODE_VERSION }}
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Run Lint
run: npm run lint
# --- Testing Stage (Example: Node.js/Jest) ---
- name: Run Tests
run: npm test
# --- Build Stage (Docker Image) ---
- name: Log in to GitHub Container Registry
uses: docker/login-action@v3
with:
registry: ${{ env.DOCKER_REGISTRY }}
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Build and push Docker image
uses: docker/build-push-action@v5
with:
context: .
push: true
tags: ${{ env.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }},${{ env.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:latest
cache-from: type=gha
cache-to: type=gha,mode=max
# Job for deploying to Development environment
deploy_dev:
needs: lint_test_build
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
environment: development # GitHub Environment for secrets/protection rules
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Deploy to Development
run: |
echo "Deploying ${{ env.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }} to Development..."
# Replace with your actual deployment commands (e.g., kubectl, AWS CLI, Azure CLI)
# Example: Update a Kubernetes deployment
# kubectl --kubeconfig <(echo "${{ secrets.KUBECONFIG_DEV }}" | base64 -d) \
# set image deployment/${{ env.PROJECT_NAME }}-dev \
# ${{ env.PROJECT_NAME }}=${{ env.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }} \
# -n dev-namespace
echo "Deployment to Development complete."
# Job for deploying to Production environment (requires manual approval)
deploy_prod:
needs: deploy_dev
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
environment: production # GitHub Environment for secrets/protection rules
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Deploy to Production
run: |
echo "Deploying ${{ env.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }} to Production..."
# Replace with your actual deployment commands
# Example: Update a Kubernetes deployment
# kubectl --kubeconfig <(echo "${{ secrets.KUBECONFIG_PROD }}" | base64 -d) \
# set image deployment/${{ env.PROJECT_NAME }}-prod \
# ${{ env.PROJECT_NAME }}=${{ env.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }} \
# -n prod-namespace
echo "Deployment to Production complete."
Customization Notes for GitHub Actions:
env: Update PROJECT_NAME, DOCKER_REGISTRY, and NODE_VERSION (or other language-specific versions).npm run lint and npm test for your specific language/framework (e.g., pytest, mvn test, go test).echo commands with actual deployment scripts or CLI commands (e.g., aws ecs update-service, az webapp deploy, kubectl apply).secrets.KUBECONFIG_DEV, secrets.AWS_ACCESS_KEY_ID, secrets.AWS_SECRET_ACCESS_KEY) for sensitive information. Define these in your repository settings under "Secrets and variables" -> "Actions".Filename: .gitlab-ci.yml
This pipeline defines stages for linting, testing, building, and deploying. It uses GitLab's built-in Docker registry and environment features.
stages:
- lint
- test
- build
- deploy-dev
- deploy-prod
variables:
# Customize these variables for your project
PROJECT_NAME: my-web-app
DOCKER_IMAGE_NAME: $CI_REGISTRY_IMAGE/$PROJECT_NAME
# Example: For a Node.js app
NODE_VERSION: '18'
default:
# Use a base image for common operations or specific runners
image: alpine/git:latest # Or a more feature-rich image like 'node:${NODE_VERSION}-alpine' for all stages
# --- Linting Stage (Example: Node.js/ESLint) ---
lint:
stage: lint
image: node:${NODE_VERSION}-alpine # Use a specific image for this job
script:
- npm ci
- npm run lint
artifacts:
expire_in: 1 day
paths:
- node_modules/ # Cache node_modules if needed for subsequent jobs
# --- Testing Stage (Example: Node.js/Jest) ---
test:
stage: test
image: node:${NODE_VERSION}-alpine
script:
- npm ci # Re-install dependencies if not cached or shared
- npm test
artifacts:
reports:
junit: junit.xml # Optional: for test report visualization in GitLab
# --- Build Stage (Docker Image) ---
build_docker_image:
stage: build
image: docker:latest # Docker-in-Docker (dind) service required for building images
services:
- docker:dind
script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker build -t $DOCKER_IMAGE_NAME:$CI_COMMIT_SHA -t $DOCKER_IMAGE_NAME:latest .
- docker push $DOCKER_IMAGE_NAME:$CI_COMMIT_SHA
- docker push $DOCKER_IMAGE_NAME:latest
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
# --- Deployment to Development Environment ---
deploy_to_dev:
stage: deploy-dev
image: alpine/git:latest # Or an image with your deployment tools (kubectl, aws-cli, etc.)
environment:
name: development
url: https://dev.example.com
script:
- echo "Deploying $DOCKER_IMAGE_NAME:$CI_COMMIT_SHA to Development..."
# Replace with your actual deployment commands
# Example: Update a Kubernetes deployment
# kubectl config use-context "$KUBE_CONTEXT_DEV"
# kubectl set image deployment/$PROJECT_NAME-dev $PROJECT_NAME=$DOCKER_IMAGE_NAME:$CI_COMMIT_SHA -n dev-namespace
echo "Deployment to Development complete."
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
# --- Deployment to Production Environment (Manual Approval) ---
deploy_to_prod:
stage: deploy-prod
image: alpine/git:latest # Or an image with your deployment tools
environment:
name: production
url: https://prod.example.com
script:
- echo "Deploying $DOCKER_IMAGE_NAME:$CI_COMMIT_SHA to Production..."
# Replace with your actual deployment commands
# kubectl config use-context "$KUBE_CONTEXT_PROD"
# kubectl set image deployment/$PROJECT_NAME-prod $PROJECT_NAME=$DOCKER_IMAGE_NAME:$CI_COMMIT_SHA -n prod-namespace
echo "Deployment to Production complete."
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
when: manual # Requires a manual trigger in the GitLab UI
Customization Notes for GitLab CI:
variables: Adjust PROJECT_NAME, DOCKER_IMAGE_NAME, and NODE_VERSION. CI_REGISTRY_IMAGE is a predefined GitLab variable for your project's container registry.image: Specify the Docker image required for each job. Use docker:dind (Docker-in-Docker) for the build_docker_image job.npm ci, npm run lint, and npm test as per your tech stack.echo commands with your specific deployment logic. GitLab CI/CD Variables (e.g., KUBE_CONTEXT_DEV, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) should be used for secrets, configured in Settings > CI/CD > Variables.rules: Control when jobs run. when: manual is used for manual approval for production deployments.environment: Define environments for better organization, history, and integration with GitLab's deployment boards.**