Skip to content

Beyond Basic Branches: Optimizing CI/CD with AWS CodePipeline's New Triggers and Monorepo Support

The cloud is vast, but fear not, fellow traveler! Automating your release pipelines is crucial for fast and reliable software delivery. AWS CodePipeline, a powerful managed continuous delivery service, has recently introduced some game-changing features: new triggers and flexible execution modes. These updates significantly enhance how we can build CI/CD pipelines, especially for teams using branch-based development and monorepos.

In this post, we'll dive into these new features and explore how you can use them to create more efficient and tailored pipelines. We'll walk through three practical examples that show you how to leverage these advancements.

Understanding New Execution Modes

Before we jump into pipelines, let's quickly understand the new execution modes:

  • Queued: When multiple pipeline executions are triggered, they run one after another, in the order they were started. This is great for environments where sequential deployments are critical, like a production release pipeline.
  • Parallel: Multiple pipeline executions can run at the same time. This mode is perfect for development workflows where you want to unblock developers and run tests concurrently, such as for feature branches or pull requests.

Now, let's look at how these modes and new triggers can be used!

Pipeline #1: Creating a GitFlow Release Pipeline

GitFlow is a popular branching model that helps manage large projects with parallel development and releases. It typically involves long-running main and develop branches, alongside short-lived feature, release, and hotfix branches.

With CodePipeline's new triggers, we can set up a single pipeline that smartly handles changes to these core GitFlow branches.

How to Set It Up:

  1. Pipeline Settings: When creating your pipeline, choose the Queued execution mode. This ensures that pushes to your main, develop, hotfix, and release branches are processed in order, preventing deployment conflicts. Make sure to select V2 for Pipeline type.

    • (Imagine a screenshot here showing "Queued" execution mode selected in CodePipeline console.)
  2. Source Stage Configuration: Connect your source provider (like GitHub). The magic happens in the Trigger settings. Select Specify filter and configure a Push event type. For branches, use an Include pattern like: main,develop,hotfix/**,release/**. This tells CodePipeline to only trigger the pipeline when changes are pushed to these specific branches.

    # Example for branch filter in CloudFormation/CLI (Conceptual)
    Triggers:
      - ProviderType: CodeStarSourceConnection
        GitBranchFilters:
          - Type: INCLUDE
            Pattern: main
          - Type: INCLUDE
            Pattern: develop
          - Type: INCLUDE
            Pattern: hotfix/**
          - Type: INCLUDE
            Pattern: release/**
        EventType: PUSH
    • (Imagine a screenshot here showing the branch filter configuration.)

This setup ensures that any push to your main release-oriented branches automatically kicks off a queued pipeline execution, making your GitFlow strategy smooth and controlled.

Pipeline #2: Running a Pipeline on All Pull Requests (PRs)

A common CI practice is to run automated checks (builds, tests, linting) when a pull request is opened or updated, before it's merged. This catches issues early and ensures only validated code lands in your main branches.

How to Set It Up:

  1. Pipeline Settings: For a PR validation pipeline, select the Parallel execution mode. This is key because multiple developers will be opening and updating PRs concurrently, and you don't want one PR's validation to block another.

    • (Imagine a screenshot here showing "Parallel" execution mode selected.)
  2. Source Stage Configuration: In the Trigger settings, select Pull Request as the Event type. You'll want to choose Pull request is created and New revision is made to pull request. For the Branches filter, simply use ** (two asterisks) in the Include field. This catches all pull requests across all branches.

    # Example for PR trigger in CloudFormation/CLI (Conceptual)
    Triggers:
      - ProviderType: CodeStarSourceConnection
        GitBranchFilters:
          - Type: INCLUDE
            Pattern: "**"
        EventType: PULL_REQUEST
        Events:
          - PULL_REQUEST_CREATED
          - PULL_REQUEST_UPDATED
    • (Imagine a screenshot here showing the pull request trigger configuration.)

This PR pipeline allows your team to quickly validate proposed changes in isolation, ensuring code quality and freeing up developers without waiting for sequential builds.

Pipeline #3: Running a Pipeline on a Single Folder Within a Monorepo

Monorepos, where a single repository holds code for many projects, are becoming increasingly popular. However, running all pipelines for every project on every commit in a monorepo can be inefficient and costly. CodePipeline now offers a smart solution using file path filters.

How to Set It Up:

  1. Pipeline Settings: For this scenario, the default Superseded execution mode is often sufficient. This mode ensures that if a new execution starts while another is still running for the same source, the older one is stopped and the new one takes precedence.

  2. Source Stage Configuration: Configure a Push event type. For the Branches filter, specify main (or your primary development branch). The crucial part here is the File paths filter. In the Include field, enter the path to your specific folder, for example: infrastructure/**.

    # Example for file path filter in CloudFormation/CLI (Conceptual)
    Triggers:
      - ProviderType: CodeStarSourceConnection
        GitBranchFilters:
          - Type: INCLUDE
            Pattern: main
        FilePathFilters:
          - Type: INCLUDE
            Pattern: infrastructure/**
        EventType: PUSH
    • (Imagine a screenshot here showing the file path filter configuration.)

With this setup, your pipeline will only trigger when changes are made within the specified infrastructure folder on your main branch. This drastically reduces unnecessary pipeline runs, saving time, resources, and cost.

Conclusion

AWS CodePipeline's new triggers and execution modes are powerful additions that provide immense flexibility for building modern CI/CD pipelines. Whether you're adopting GitFlow, needing robust pull request validation, or streamlining monorepo deployments, these features accelerate your software delivery.

"Let's architect for scale." By wisely using these new capabilities, you can ensure your "observability is key" and your "code your infrastructure" philosophy truly shines, leading to more efficient and resilient cloud-native applications. Check out the AWS CodePipeline User Guide to dive deeper and automate your delivery workflows today!