CI/CD Pipeline Automation: Building a Fully Automated Deployment System from Scratch

In today’s fast-paced software development landscape, the ability to deliver code changes quickly, reliably, and consistently has become a competitive necessity. Continuous Integration and Continuous Deployment (CI/CD) pipelines are the backbone of modern software delivery, enabling teams to automate the tedious and error-prone manual processes that traditionally slowed down development cycles. This comprehensive tutorial will guide you through building a robust CI/CD pipeline from scratch, providing practical examples and best practices for each stage of the automation journey. As part of this journey, we’ll also explore the critical aspect of database changes automation in CI/CD, ensuring that your database schema and data migrations are just as seamless and reliable as your application code deployments. By integrating database changes into your CI/CD pipelines, you can maintain synchronized versions of your application and its underlying data, reducing the risk of errors and enhancing collaboration across development teams. This holistic approach to automation will empower you to deliver higher quality software at a faster pace while minimizing the manual effort involved in deployment processes.

Understanding CI/CD: The Foundation of Modern Software Delivery

Before diving into the technical implementation, it’s essential to understand what CI/CD is and why it’s transformative for development teams.

Continuous Integration (CI) is the practice of frequently merging code changes into a shared repository, where automated builds and tests verify each integration. This approach catches integration issues early, when they’re easier and less expensive to fix. Continuous Deployment (CD) extends this automation to the delivery and deployment phases, enabling teams to release changes to production quickly and reliably.

According to the 2023 State of DevOps Report, high-performing organizations that implement CI/CD effectively deploy code 208 times more frequently and recover from incidents 24 times faster than their lower-performing counterparts. These organizations also report higher levels of employee satisfaction and lower burnout rates—clear indicators that automation delivers benefits beyond just technical metrics.

Prerequisites for Building Your CI/CD Pipeline

Before we begin constructing our pipeline, ensure you have:

• A version control system (Git recommended) with a hosted repository (GitHub, GitLab, or Bitbucket)
• A basic application to deploy (we’ll use a simple Node.js web application in our examples)
• Access to a cloud provider for deployment (AWS, Azure, or GCP)
• Basic understanding of containerization concepts (Docker)
• Administrative access to install and configure the necessary tools

The CI/CD Pipeline Architecture

Our pipeline will follow a modern architecture with these key components:

1. Source Code Management: Git repository with branch protection rules
2. Build Automation: Compiling code and creating deployable artifacts
3. Automated Testing: Unit tests, integration tests, and end-to-end tests
4. Security Scanning: Detecting vulnerabilities in code and dependencies
5. Artifact Storage: Storing build outputs securely
6. Infrastructure Provisioning: Creating and managing deployment environments
7. Deployment Automation: Rolling out changes to different environments
8. Monitoring and Feedback: Verifying deployment success and performance

Now, let’s build each component step by step.

Step 1: Setting Up Source Code Management

A well-configured version control system forms the foundation of your CI/CD pipeline.

Creating and Configuring Your Git Repository

For this tutorial, we’ll use GitHub as our source code management platform.

1. Create a new repository on GitHub for your project
2. Initialize the repository with a README.md file and .gitignore appropriate for your project type
3. Clone the repository to your local machine:

git clone https://github.com/yourusername/your-project.git
cd your-project

Implementing Branch Protection and Collaboration Workflows

Configure branch protection rules to enforce quality standards:

1. Navigate to your repository’s Settings > Branches
2. Add a rule for your main branch with these settings:

• Require pull request reviews before merging
• Require status checks to pass before merging
• Require branches to be up to date before merging
• Include administrators in these restrictions

Establish a branching strategy. For this tutorial, we’ll use a simplified Git Flow approach:

• main: Production-ready code
• develop: Integration branch for features
• feature/*: New features and enhancements
• hotfix/*: Emergency fixes for production

Creating a Sample Application

Let’s set up a simple Node.js application to demonstrate our pipeline:

# Initialize a new Node.js project
npm init -y

# Install Express.js
npm install express

# Create a basic server file
cat > index.js << EOF
const express = require('express');
const app = express();
const port = process.env.PORT || 3000;

app.get('/', (req, res) => {
  res.send('Hello CI/CD World!');
});

app.listen(port, () => {
  console.log(\`Application listening on port \${port}\`);
});
EOF

# Create a simple test
mkdir test
cat > test/index.test.js << EOF
const assert = require('assert');

describe('Sample Test', () => {
  it('should return true', () => {
    assert.strictEqual(true, true);
  });
});
EOF

# Add testing dependencies
npm install --save-dev mocha

# Update package.json with test script
npm pkg set scripts.test="mocha"

Commit these changes to your repository:

git add .
git commit -m "Initial application setup"
git push origin main

Step 2: Building Your Continuous Integration Workflow

Now, let’s set up the CI portion of our pipeline, which will automatically build and test our code whenever changes are pushed.

Setting Up GitHub Actions for CI

GitHub Actions provides a convenient way to automate workflows directly from your repository.

1. Create a .github/workflows directory in your project:

mkdir -p .github/workflows

2. Create a CI workflow file:

cat > .github/workflows/ci.yml << EOF
name: Continuous Integration

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main, develop ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3

    - name: Setup Node.js
      uses: actions/setup-node@v3
      with:
        node-version: 16
        cache: 'npm'

    - name: Install dependencies
      run: npm ci

    - name: Run tests
      run: npm test

    - name: Lint code
      run: npm run lint || echo "No linting configured"
EOF

3. Let’s enhance our sample application with linting to demonstrate a more comprehensive CI process:

# Install ESLint
npm install --save-dev eslint

# Initialize ESLint configuration
npx eslint --init
# Follow the prompts to set up a basic configuration

# Update package.json with lint script
npm pkg set scripts.lint="eslint ."

4. Commit these changes:

git add .
git commit -m "Add CI workflow and linting"
git push origin main

Understanding CI Workflow Execution

When you push these changes, GitHub Actions will automatically execute the workflow. You can monitor the progress by navigating to the “Actions” tab in your repository.

The workflow performs several key CI functions:

• Checking out your code
• Setting up the Node.js environment
• Installing dependencies
• Running automated tests
• Linting your code for style and potential errors

Adding Code Quality Checks

Let’s enhance our CI pipeline with code quality checks using SonarCloud:

1. Sign up for a free SonarCloud account and connect it to your GitHub repository
2. Update your CI workflow file to include SonarCloud analysis:

- name: SonarCloud Scan
  uses: SonarSource/sonarcloud-github-action@master
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

3. Create a sonar-project.properties file in your repository:

sonar.projectKey=your-project-key
sonar.organization=your-organization

sonar.sources=.
sonar.exclusions=node_modules/**,test/**
sonar.tests=test

sonar.javascript.lcov.reportPaths=coverage/lcov.info

4. Add test coverage reporting to your project:

# Install Jest and coverage dependencies
npm install --save-dev jest jest-sonar-reporter

# Update package.json
npm pkg set scripts.test="jest --coverage"
npm pkg set jest.testEnvironment="node"
npm pkg set jest.coverageReporters="['lcov', 'text-summary']"
npm pkg set jest.testResultsProcessor="jest-sonar-reporter"

5. Update your test file to be compatible with Jest:

test('Sample Test', () => {
  expect(true).toBe(true);
});

With these changes, your CI pipeline now includes automated code quality analysis that identifies bugs, vulnerabilities, and code smells.

Step 3: Containerizing Your Application

Containerization ensures that your application runs consistently across different environments, making it crucial for reliable deployment.

Creating a Docker Configuration

1. Create a Dockerfile in your project root:

cat > Dockerfile << EOF
FROM node:16-alpine

WORKDIR /app

COPY package*.json ./

RUN npm ci --only=production

COPY . .

EXPOSE 3000

CMD ["node", "index.js"]
EOF

2. Create a .dockerignore file to exclude unnecessary files:

cat > .dockerignore << EOF
node_modules
npm-debug.log
coverage
.git
.github
.gitignore
README.md
EOF

3. Update the CI workflow to build and test the Docker image:

- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@v2

- name: Build Docker image
  uses: docker/build-push-action@v3
  with:
    context: .
    push: false
    load: true
    tags: myapp:test

- name: Test Docker image
  run: |
    docker run --rm myapp:test node -e "console.log('Container works!')"

4. Commit these changes:

git add .
git commit -m "Add Docker configuration"
git push origin main

Setting Up a Container Registry

To store and distribute our Docker images, we’ll use GitHub Container Registry:

1. Update the CI workflow to include authentication and pushing to GitHub Container Registry:

- name: Login to GitHub Container Registry
  if: github.event_name != 'pull_request'
  uses: docker/login-action@v2
  with:
    registry: ghcr.io
    username: ${{ github.actor }}
    password: ${{ secrets.GITHUB_TOKEN }}

- name: Build and push Docker image
  if: github.event_name != 'pull_request'
  uses: docker/build-push-action@v3
  with:
    context: .
    push: true
    tags: |
      ghcr.io/${{ github.repository }}:${{ github.sha }}
      ghcr.io/${{ github.repository }}:latest

This configuration builds and pushes a Docker image with two tags: one based on the commit SHA for immutable references, and a “latest” tag for convenience.

Step 4: Implementing Continuous Deployment

Now that we have a solid CI process that builds, tests, and containerizes our application, let’s set up the Continuous Deployment portion of our pipeline.

Creating Infrastructure as Code with Terraform

We’ll use Terraform to define our infrastructure in a reproducible way:

1. Install Terraform on your local machine
2. Create a terraform directory in your project:

mkdir -p terraform

3. Create a basic AWS infrastructure configuration:

cat > terraform/main.tf << EOF
provider "aws" {
  region = "us-east-1"
}

resource "aws_ecr_repository" "app_repo" {
  name = "myapp-repository"
}

resource "aws_ecs_cluster" "app_cluster" {
  name = "myapp-cluster"
}

resource "aws_ecs_task_definition" "app_task" {
  family                   = "myapp"
  container_definitions    = jsonencode([
    {
      name      = "myapp"
      image     = "\${aws_ecr_repository.app_repo.repository_url}:latest"
      cpu       = 256
      memory    = 512
      essential = true
      portMappings = [
        {
          containerPort = 3000
          hostPort      = 3000
        }
      ]
    }
  ])
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  cpu                      = "256"
  memory                   = "512"
  execution_role_arn       = aws_iam_role.ecs_execution_role.arn
}

resource "aws_iam_role" "ecs_execution_role" {
  name = "myapp-ecs-execution-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "ecs-tasks.amazonaws.com"
        }
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "ecs_execution_role_policy" {
  role       = aws_iam_role.ecs_execution_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
}
EOF

4. Add Terraform to the CI workflow to validate the infrastructure code:

- name: Setup Terraform
  uses: hashicorp/setup-terraform@v2

- name: Terraform Format
  run: |
    cd terraform
    terraform fmt -check

- name: Terraform Init
  run: |
    cd terraform
    terraform init

- name: Terraform Validate
  run: |
    cd terraform
    terraform validate

Creating a Deployment Workflow

Now, let’s create a separate workflow for deployment:

cat > .github/workflows/cd.yml << EOF
name: Continuous Deployment

on:
  push:
    branches: [ main ]
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    needs: build-and-test  # This would reference the CI job if both were in the same workflow

    environment: production  # Using GitHub Environments for deployment approvals

    steps:
    - uses: actions/checkout@v3

    - name: Setup Terraform
      uses: hashicorp/setup-terraform@v2

    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: \${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: \${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: us-east-1

    - name: Terraform Init
      run: |
        cd terraform
        terraform init

    - name: Terraform Apply
      run: |
        cd terraform
        terraform apply -auto-approve

    - name: Login to Amazon ECR
      id: login-ecr
      uses: aws-actions/amazon-ecr-login@v1

    - name: Build, tag, and push image to Amazon ECR
      env:
        ECR_REGISTRY: \${{ steps.login-ecr.outputs.registry }}
        ECR_REPOSITORY: myapp-repository
        IMAGE_TAG: \${{ github.sha }}
      run: |
        docker build -t \$ECR_REGISTRY/\$ECR_REPOSITORY:\$IMAGE_TAG .
        docker push \$ECR_REGISTRY/\$ECR_REPOSITORY:\$IMAGE_TAG
        docker tag \$ECR_REGISTRY/\$ECR_REPOSITORY:\$IMAGE_TAG \$ECR_REGISTRY/\$ECR_REPOSITORY:latest
        docker push \$ECR_REGISTRY/\$ECR_REPOSITORY:latest

    - name: Update ECS service
      run: |
        aws ecs update-service --cluster myapp-cluster --service myapp-service --force-new-deployment
EOF

Setting Up Multiple Deployment Environments

In a real-world scenario, you’ll want separate environments for testing and production. Let’s enhance our CD workflow to support this:

1. Create a new file for environment-specific Terraform variables:

cat > terraform/dev.tfvars << EOF
environment = "development"
instance_type = "t3.micro"
EOF

cat > terraform/prod.tfvars << EOF
environment = "production"
instance_type = "t3.small"
EOF

2. Update the CD workflow to deploy to different environments based on the branch:

jobs:
  deploy-development:
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/develop'
    environment: development

    # Steps similar to above but using dev.tfvars

  deploy-production:
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    environment: production

    # Steps similar to above but using prod.tfvars

With this configuration, code pushed to the develop branch is automatically deployed to the development environment, while code pushed to the main branch is deployed to production, subject to any approval rules you’ve configured in GitHub Environments.

Step 5: Implementing Continuous Security

Security should be integrated throughout your CI/CD pipeline rather than treated as an afterthought.

Adding Automated Security Scanning

1. Update the CI workflow to include security scanning:

- name: Run dependency vulnerability scan
  uses: snyk/actions/node@master
  with:
    args: --severity-threshold=high
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

- name: Run Docker image scan
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: myapp:test
    format: 'sarif'
    output: 'trivy-results.sarif'
    severity: 'CRITICAL,HIGH'

2. For infrastructure security, add TFSec to scan your Terraform code:

- name: Run Terraform security scan
  uses: aquasecurity/tfsec-action@v1.0.0
  with:
    working_directory: terraform

Implementing Secrets Management

Proper secrets management is crucial for pipeline security. Set up GitHub Secrets for sensitive information:

1. Navigate to your repository’s Settings > Secrets and variables > Actions
2. Add secrets for:

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• SNYK_TOKEN
• SONAR_TOKEN

Never hardcode sensitive information in your repository or Docker images. Always inject secrets at runtime using environment variables or a dedicated secrets management service.

Step 6: Monitoring and Feedback Loops

The final component of a mature CI/CD pipeline is effective monitoring and feedback.

Setting Up Application Monitoring

1. Add a health check endpoint to your application:

app.get('/health', (req, res) => {
  res.status(200).send('OK');
});

2. Configure AWS CloudWatch for monitoring and alerts:

resource "aws_cloudwatch_metric_alarm" "service_health" {
  alarm_name          = "myapp-health"
  comparison_operator = "LessThanThreshold"
  evaluation_periods  = "2"
  metric_name         = "HealthyHostCount"
  namespace           = "AWS/ApplicationELB"
  period              = "60"
  statistic           = "Average"
  threshold           = "1"
  alarm_description   = "This metric monitors the health of the application"
  dimensions = {
    TargetGroup = aws_lb_target_group.app.arn_suffix
    LoadBalancer = aws_lb.app.arn_suffix
  }
}

Adding Post-Deployment Tests

To verify your deployment was successful, add post-deployment smoke tests:

- name: Run smoke tests
  run: |
    # Wait for service to be available
    sleep 30

    # Run basic HTTP check
    curl -f https://your-application-url/health || exit 1

    # Run more comprehensive integration tests
    npm run test:integration

Implementing Feature Flags

Feature flags allow you to deploy code to production but selectively enable features for specific users or environments. This reduces deployment risk and enables more frequent releases:

1. Install a feature flag library:

npm install unleash-client

2. Configure feature flags in your application:

const { initialize, isEnabled } = require('unleash-client');

initialize({
  url: 'https://your-unleash-server/api',
  appName: 'myapp',
  environment: process.env.NODE_ENV
});

app.get('/new-feature', (req, res) => {
  if (isEnabled('newFeature')) {
    res.send('New feature is enabled!');
  } else {
    res.send('New feature coming soon!');
  }
});

By implementing feature flags, you can release features independently of deployment, which is a powerful capability for modern development teams. For an excellent breakdown of feature flag implementation strategies, you can refer to CloudRank’s guide on progressive delivery techniques which covers advanced usage of feature flags in CI/CD pipelines.

Advanced CI/CD Pipeline Considerations

As your pipeline matures, consider these advanced techniques:

Implementing Blue/Green Deployments

Blue/green deployments maintain two identical production environments, with only one active at a time. This allows for zero-downtime deployments and easy rollbacks:

resource "aws_ecs_service" "app" {
  name            = "myapp-service"
  cluster         = aws_ecs_cluster.app_cluster.id
  task_definition = aws_ecs_task_definition.app_task.arn
  desired_count   = 2

  deployment_controller {
    type = "CODE_DEPLOY"
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.app_blue.arn
    container_name   = "myapp"
    container_port   = 3000
  }
}

resource "aws_codedeploy_app" "app" {
  name             = "myapp"
  compute_platform = "ECS"
}

resource "aws_codedeploy_deployment_group" "app" {
  app_name               = aws_codedeploy_app.app.name
  deployment_group_name  = "myapp-deployment-group"
  service_role_arn       = aws_iam_role.codedeploy_service_role.arn

  blue_green_deployment_config {
    deployment_ready_option {
      action_on_timeout = "CONTINUE_DEPLOYMENT"
    }

    terminate_blue_instances_on_deployment_success {
      action = "TERMINATE"
      termination_wait_time_in_minutes = 5
    }
  }
}

Implementing Canary Deployments

Canary deployments gradually shift traffic from the old version to the new version, allowing you to monitor for issues with a small subset of users before rolling out to everyone:

- name: Deploy canary
  run: |
    # Deploy new version but only route 10% of traffic to it
    aws ecs update-service --cluster myapp-cluster --service myapp-service --task-definition myapp:${{ github.sha }} --desired-count 1
    aws cloudwatch put-metric-alarm --alarm-name "myapp-canary-errors" --alarm-description "Alert on errors in canary deployment" --namespace "AWS/ApplicationELB" --metric-name "HTTPCode_Target_5XX_Count" --statistic "Sum" --period 60 --evaluation-periods 1 --threshold 1 --comparison-operator "GreaterThanThreshold"

- name: Wait and evaluate canary
  run: |
    sleep 300  # Wait 5 minutes
    # Check if alarm triggered
    ALARM_STATE=$(aws cloudwatch describe-alarms --alarm-names "myapp-canary-errors" --query "MetricAlarms[0].StateValue" --output text)
    if [ "$ALARM_STATE" = "ALARM" ]; then
      echo "Canary deployment showing errors, rolling back"
      aws ecs update-service --cluster myapp-cluster --service myapp-service --task-definition myapp:${{ github.ref }}-previous --desired-count 2
      exit 1
    fi

    # Complete deployment if all is well
    aws ecs update-service --cluster myapp-cluster --service myapp-service --task-definition myapp:${{ github.sha }} --desired-count 2

FAQ: CI/CD Pipeline Automation

How often should my CI/CD pipeline run?

Your CI pipeline should run on every code change, including all pull requests, to provide immediate feedback to developers. CD pipelines typically run after successful CI jobs, but only on specific branches (like main or develop) or with manual approvals for production deployments. High-performing teams aim for multiple deployments per day to production, even if features are hidden behind feature flags.

How can I optimize my CI/CD pipeline for speed?

Several strategies can improve pipeline performance:

• Parallelize tasks that don’t depend on each other
• Implement efficient caching of dependencies and build artifacts
• Use incremental builds where possible
• Optimize test suites to run faster tests first and fail fast
• Scale your CI/CD infrastructure to handle concurrent builds
• Consider using spot instances for cost-effective scaling

What are the security best practices for CI/CD pipelines?

Security should be integrated throughout your pipeline:

• Scan code for vulnerabilities during CI using SAST tools
• Scan dependencies for known vulnerabilities
• Scan container images before deployment
• Use least-privilege IAM roles for your pipeline
• Implement branch protection and code review requirements
• Store secrets securely and rotate them regularly
• Sign artifacts to verify authenticity
• Implement infrastructure security scanning

How do I handle database migrations in CI/CD pipelines?

Database migrations require special care:

• Version your database schema changes alongside application code
• Test migrations in CI against a duplicate of your production schema
• Use tools that support rollback capabilities for failed migrations
• Consider using blue/green deployments with schema versioning
• Implement zero-downtime migration patterns for critical applications
• Always backup the database before applying migrations in production

What metrics should I track to evaluate CI/CD pipeline effectiveness?

Key metrics for evaluating pipeline performance include:

• Deployment frequency: How often you successfully deploy to production
• Lead time for changes: Time from code commit to successful production deployment
• Change failure rate: Percentage of deployments that cause failures in production
• Mean time to recovery: How long it takes to recover from failures
• Pipeline execution time: Total time to run the complete pipeline
• Test coverage and quality: Ensuring comprehensive testing

How can I implement CI/CD in a regulated industry with compliance requirements?

Regulated industries can still benefit from CI/CD:

• Implement approval gates where required by compliance
• Maintain comprehensive audit logs of all pipeline activities
• Integrate compliance checks as automated steps in your pipeline
• Use infrastructure as code to ensure consistent, compliant environments
• Implement separation of duties through pipeline role restrictions
• Document everything for auditors, including pipeline configurations
• Consider specialized CI/CD tools with compliance features for industries like healthcare or finance

How do I handle environment-specific configuration in my CI/CD pipeline?

Environment configuration should be:

• Stored separately from application code
• Protected based on sensitivity (using secrets management for credentials)
• Injected at deployment time rather than build time
• Defined as code using infrastructure as code tools
• Version-controlled when possible (except for secrets)
• Validated as part of the pipeline to catch configuration errors early

What’s the difference between Continuous Delivery and Continuous Deployment?

Continuous Delivery automates the build, test, and preparation of code for release to production, with a manual approval step for the actual deployment. Continuous Deployment takes this one step further by automatically deploying to production after all tests pass, with no manual intervention. The choice between them depends on your business requirements, regulatory environment, and risk tolerance.

How can I gradually introduce CI/CD to a legacy project?

Start small and incrementally improve:

1. Begin with version control if not already in place
2. Implement automated builds for the current process
3. Gradually add automated tests, focusing on critical paths
4. Create deployment scripts to automate manual steps
5. Introduce environment-specific configurations
6. Implement a basic deployment pipeline for non-production environments
7. Gradually extend automation to production as confidence grows

How do I handle rollbacks when a deployment fails?

Implement a robust rollback strategy:

• Store deployment artifacts with immutable versioning
• Maintain previous working infrastructure configurations
• Use blue/green deployments for instant rollbacks
• Implement automated rollback triggers based on monitoring
• Test rollback procedures regularly as part of your pipeline
• Consider database changes carefully, as they may not be easily reversible

By building a comprehensive CI/CD pipeline following these practices, you’ll create a reliable, efficient system for delivering software that can evolve with your organization’s needs. The initial investment in automation will pay dividends through faster delivery, higher quality, and reduced operational burden.

Please leave this field empty

Oh hi there 👋
It’s nice to meet you.

Sign up to receive the ultimate content in your inbox, every month.

We don’t spam! Read our privacy policy for more info.

Check your inbox or spam folder to confirm your subscription.