An introduction to the build pipeline, and how we can orchestrate it manually

Before working with CMake, it's useful to understand the tools it orchestrates. This lesson guides you through setting up a C++ toolchain.

Building C++ Programs

Walking through the steps of the C++ compilation process, from source code to machine code.

The Compilation Pipeline

The linker's role in the build process, how it resolves symbols to combine object files, and how to troubleshoot common errors.

Object Files and the Linking Process

The difference between static and dynamic libraries, how to create them, and the trade-offs between them.

Static and Shared Libraries

The C++ Build Process

Recommended approaches for managing large projects and the libraries that they depend on

Learn how to structure your C++ projects for scalability and maintainability, from basic directory layouts to managing multiple modules.

Organizing a C++ Project

Learn to manage third-party libraries in C++, covering include/library paths, static vs. shared libraries, versioning, and platform differences.

Managing Libraries and Dependencies

An introduction to traditional build tools like Makefiles and IDE projects, highlighting the maintenance, scalability, and cross-platform challenges that result

Automated Build Systems and Their Limitations

Project Structure and Dependency Management

Setting up CMake and creating your first project

An introduction to CMake, the cross-platform, open-source meta-build system that solves the core challenges of C++ project management.

Why CMake?

A step-by-step guide to installing CMake. We'll explore command-line, GUI, and IDE workflows, and how to configure your compiler.

Setting Up a CMake Environment

Creating the bare minimum `CMakeLists.txt` file and build up to a project with an executable and a library, learning the fundamental commands along the way.

Writing a CMakeLists File

Learn the two-stage process of building a CMake project. This lesson covers configuring, generating, building, running, and troubleshooting common errors.

Building and Running CMake Projects

Learn how to organize large C++ projects in CMake using subdirectories and the `add_subdirectory()` command to create modular, maintainable builds.

CMake Project Structure and Subdirectories

Introducing CMake

Exploring CMake's programming features, caching mechanisms, and interactions with the file system

A primer on the fundamental building blocks of the CMake language: variables, string interpolation, and logging messages.

CMake Variables and Logging

Discover the CMake Cache, the mechanism for storing persistent user-configurable options, and learn how to create and manage cached variables.

The CMake Cache

Exploring CMake's command syntax and its list data type, including how to create, manipulate, and use lists in your projects.

CMake Commands, Arguments, and Lists

Transform your static build descriptions into dynamic scripts with CMake's control flow commands, if() and foreach().

CMake Conditionals and Loops

Exploring CMake's `file()` command, covering how to read, write, copy, and glob files, and how to manipulate paths.

Working with the File System

Learn to create reusable logic with CMake functions and macros, and how to organize them into modules for clean, scalable build systems.

Modularizing CMake Code

CMake Language and Fundamentals

Learn more about targets, and how their properties and links are the foundation of modern CMake

Learn to work with target properties - understanding their purpose, setting and updating them, and retrieving them when your build requires it

Target Properties

Learn about target types, and how the `PUBLIC`, `PRIVATE`, and `INTERFACE` keywords control how properties are shared.

Relationships Between Targets

Discover how CMake's `target_link_libraries()` command builds a dependency graph, and how it uses this graph to automatically manage transitive dependencies and link order.

Indirect Relationships and the Dependency Graph

Learn to use abstract target types like `INTERFACE`, `ALIAS`, and `IMPORTED` to model complex project needs, organize build properties, and integrate pre-compiled binaries.

Using `INTERFACE`, `ALIAS`, and `IMPORTED` Libraries

Adding support for user-configurable library types and an initial introduction to target installation.

Using Shared Libraries

Targets and Dependencies

Learn how to manage multiple build configurations within the same project, and how to create scripts that adapt to the environment

Learn how CMake manages different build configurations like Debug and Release, the difference between generator types, and how to apply settings conditionally using modern techniques.

Build Configurations (Debug, Release, etc.)

Learn the tools and patterns needed to write portable CMakeLists.txt files that work seamlessly across platforms and compilers

Cross-Platform Configurations

Learn to write architecture-aware CMake scripts for 32/64-bit systems and Apple's Universal Binaries (Intel/ARM).

Handling Different Architectures

Learn to build for different operating systems and architectures using CMake's cross-compilation support and toolchain files.

Cross-Compilation and Toolchain Files

Platforms and Build Configurations

Learn how to add external libraries to our build, and how to create our own packages for others to use

Learn to find and use pre-installed libraries with `find_package()`, understanding Module vs. Config mode and the power of imported targets

Finding Dependencies using `find_package()`

Learn how to make your libraries consumable by other projects using CMake by turning your build-tree into a distributable install-tree.

Creating a Consumable Package

Learn how to consume a CMake package you've installed, completing the producer-consumer cycle. We'll cover using `find_package()` and how to point CMake to your library's location

Using Installed Packages

Learn how to create self-contained, reproducible builds by fetching dependencies from source using `FetchContent()` and `ExternalProject_Add()`.

Fetching External Dependencies

Creating and Consuming Packages

Integrating the vcpkg and Conan package managers to handle external dependencies

Learn to manage C++ dependencies effortlessly with the vcpkg package manager and its seamless CMake integration using toolchain files and manifests.

Integrating CMake and vcpkg

Learn the day-to-day commands for managing dependencies with vcpkg and how to guarantee reproducible builds using baselines and version overrides

vcpkg Commands and Versioning

Combine vcpkg with CMake's cross-compilation capabilities. Learn to use triplets to target different architectures and chain-load toolchain files

Cross-Compiling with vcpkg

Discover Conan, the binary-first C++ package manager, and learn how to integrate it with CMake using profiles and lockfiles for fast, reproducible builds.

Using Conan with CMake

Learn to cross-compile C++ projects with Conan, using build and host profiles to manage dependencies for different platforms.

Cross-Compilation with Conan

Package Managers

Introducing presets, allowing us to simplify our workflow and share common configurations across our team

Learn the fundamentals of CMake Presets. This lesson introduces `CMakePresets.json` to simplify complex build commands.

CMake Presets

Learn to structure your CMake presets with inheritance and customize them for your local environment using `CMakeUserPresets.json`.

User Presets and Inheritance

Learn to make your CMake presets portable by using environment variables and conditional logic to adapt to different machine configurations.

Environment Variables and Conditional Presets

Learn how to extend the build process beyond simple compilation by integrating external tools and custom commands

Learn how to use generator expressions `$<...>` for build-time conditional logic.

Generator Expressions and Conditional Logic

Learn how to attach commands to specific points in a target's build lifecycle using `add_custom_command(TARGET)` for tasks like post-build file copying.

Integrating Tools with `add_custom_command()`

Learn to integrate code generators like Protobuf into your build process using `add_custom_command()`, creating automated file-level dependencies in CMake.

Generating Files with Protobuf and `add_custom_command()`

Custom Commands

An introduction to automating common workflow chores by creating custom targets

Learn to create standalone, non-code targets using add_custom_target() for utility tasks like code formatting and documentation generation.

Custom Targets and Build Utilities

Using the Clang-Format tool to automatically enforce a consistent coding style, and integrating it into our build using a custom CMake target

Using Clang-Format

An introduction to file sets and the `target_sources()` command, allowing us to manage our header files in a more controlled way

Using File Sets

A step-by-step guide to integrating Doxygen into your CMake build process for automated C++ documentation.

Generating Documentation with Doxygen

Custom Targets

Integrate automated tests into a CMake project using CTest, GoogleTest, and GoogleMock

Learn the fundamentals of automated testing in C++ with CTest. Create your first test suite, register tests with `add_test()`, and run them with the `ctest` command.

Automated Testing and CTest

Learn to refactor manual C++ tests into a professional test suite using the GoogleTest framework, managed by vcpkg and integrated with CTest.

Integrating GoogleTest with CMake

Learn to use a wide range of assertions, write data-driven parameterized tests, and isolate dependencies with Google Mock.

Assertions and Parameterized Tests

Learn how to isolate dependencies that our project uses, and then how to replace those dependencies at test time using Google Mock.

Dependency Injection and Mocking

Learn the standard pattern for testing application logic by refactoring it into a linkable library

Testing Executables

Move beyond individual tests to manage a full test suite. Learn to organize tests, run tests in parallel, filter by labels, and measure our code coverage

Managing a Test Suite

Automated Testing

Using static and dynamic analysis in CMake projects to automatically detect memory bugs, performance issues, and problematic code

Learn to find memory bugs at runtime by integrating AddressSanitizer (ASan) into a CMake project

Using AddressSanitizer (ASan)

Adding benchmarks to our build to measure the performance of our code, and track how it changes over time

Using Google Benchmark

Integrating Clang-Tidy to enforce good practices and find bugs before we even compile

Using Clang-Tidy

Automated Analysis

Automating the entire development lifecycle using Git for souce control, GitHub Actions for cloud builds, and CPack to create distributable packages and installers.

An introduction to Git, the version control system that underpins modern collaborative software development and automated build pipelines.

Source Control with Git

Learn how to automate your build and test process with Continuous Integration (CI) and a build server. This lesson provides a guide to creating a GitHub Actions workflow for a CMake project.

Build Servers and Continuous Integration

Learn to package your C++ projects using CMake's CPack. This lesson covers creating developer ZIP archives and professional Windows MSI installers with components.

Packaging with CPack

Learn to automate the packaging process by integrating CPack with a multi-platform GitHub Actions workflow

Packaging with GitHub Actions

Learn to automate the creation of a professional Windows installer by integrating CPack, the WiX Toolset, and a multi-platform GitHub Actions workflow.

Creating Installers with CPack and GitHub Actions

Learn to automate the release process using a GitHub Actions workflow that builds, packages, and publishes artifacts to a GitHub Release

Deployment with GitHub Releases

Continuous Integration and Packaging

If you have a basic grasp of C++ but find the build process intimidating, this course is for you. We assume you know the language, but not how to manage large projects.

Manage complex, cross-platform builds using industry-standard tools. Create scalable build systems that automate the entire development lifecycle.

This course is a comprehensive deep-dive into the entire C++ build ecosystem, centered around the power and flexibility of modern CMake. We leave no stone unturned.

Start with a foundational understanding of compilers, linkers, static vs. shared libraries, and object files.

The Full Build Pipeline

Learn every aspect of the CMake language, from variables and control flow to functions, modules, and generator expressions.

Complete CMake Language Mastery

Master the modern target-centric paradigm, including properties, usage requirements, and abstract targets.

Advanced Target Management

Explore every method for handling dependencies, from `find_package` and `FetchContent` to vcpkg and Conan, including versioning and cross-compilation.

In-Depth Dependency Management

Integrate a full suite of professional tools for testing (CTest, GoogleTest), analysis (ASan, Clang-Tidy), and packaging (CPack).

Total Workflow Automation

Build a fully automated deployment pipeline that takes your code from a Git push to a published GitHub Release with multi-platform installers.

End-to-End CI/CD and Deployment

What You'll Learn

Become a software engineer with C++.  Starting from the basics, we guide you step by step along the way

Intro to C++ Programming

If you're completely new to programming or want a thorough introduction, consider starting with our free introductory course:

New to Programming?

Managing C++ Projects Using CMake

This is it. The final lesson. We've journeyed from the absolute fundamentals of the C++ build process to creating a sophisticated, multi-platform build system. We've automated testing, analysis, and packaging. Now, we'll automate the final step: **deployment**.


Deployment is the process of making your software available to end-users.  There are many ways we could do this - perhaps we sell our software on our website, or distribute it in some online marketplace.


In this example, we'll publish it as part of our GitHub repository.  A **GitHub Release** is a formal, versioned snapshot of your project, complete with release notes and downloadable files (our packaged artifacts).


Distributing via GitHub Releases is a fairly common approach, particularly for tools that are intended to be used for other developers.  For example, we've been downloading spdlog using package managers, but their [official releases](https://github.com/gabime/spdlog/releases) are published on GitHub.


<Img file="github-release-0.png" alt="Screenshot showing an spdlog release" width="612" height="857" blurHash="L1SPX{0000_300xt_3Rkx@?b4.M{" />


In this lesson, we will create a GitHub Actions workflow that builds, tests, packages, and drafts a new release for our software.


## The Manual Release Process


Before we automate, let's understand the manual process. This builds a mental model of what our workflow will be doing for us.


### Step 1: Create and Push a Git Tag


A **Git tag** is a permanent marker that points to a specific commit. It's the standard way to label a **version** in your project's history. The convention is to use a version number, often prefixed with a `v`.


Let's say we're ready to release version `1.0.0` of our `Greeter` application. From our project's root directory, we would run:


```c++
//<ti>
git tag v1.0.0
```


This creates a tag on our current commit. To make the tag visible to GitHub, we need to push it to the remote repository:


```c++
//<ti>
git push origin v1.0.0
```


### Step 2: Draft the Release on GitHub


With the tag pushed, we can go to our repository's page on GitHub, click on the "Releases" link on the right-hand side, and then click "Draft a new release".


This brings up a form where we can:

1. **Choose a tag:** Select the `v1.0.0` tag we just pushed.
2. **Write release notes:** This is where you'd write a summary of the changes since the last release (a changelog).
3. **Attach binaries:** This is where we would manually drag and drop the `.zip` and `.msi` files generated by CPack.

<Img file="github-release-manual.png" alt="Screenshot showing the manual creation of a GitHub release" width="617" height="858" blurHash="L2S?DV009EM_~X%NxbV[0J009FIU" />


Once we click "Publish release," we have a complete, public release page that users can visit to download our software. This manual process works, but it's tedious and error-prone. Let's automate it.


## Automating Releases with GitHub Actions


We'll create a new, separate workflow specifically for releases. This keeps our CI logic (which runs on every pull request) separate from our deployment logic (which only runs when we explicitly push a new version tag).


Let's create a new file at `.github/workflows/release.yml`.


### The Tag Trigger


Our CI workflow used an `on: pull_request` trigger. For our release workflow, we'll use a different trigger: `on: push: tags`.


<CodeFile path=".github/workflows/release.yml" status="New">


```yaml
name: Release

on:
  push:
    tags:
      - 'v*' # Run only when a tag starting with 'v' is pushed
  
# ...
```


</CodeFile>


This configuration tells GitHub Actions: "Run this workflow only when a Git tag is pushed to the repository, and only if that tag's name starts with a `v`." 


This ensures the workflow doesn't run on normal code pushes, only on deliberate version tags.


### Permissions


Actions we use in a GitHub workflow have some restrictions on what they can do in our repository.  For our previous CI workflow, we didn't need to intervene here.  The actions in that workflow only needed to read access to our code, and that is included by default.


However, to create a release, this new workflow will need the ability to **write** to our repository.  We can modify the permissions that actions within a workflow have by setting the `permissions` key:


<CodeFile path=".github/workflows/release.yml" status="New">


```yaml
name: Release

on:
  push:
    tags:
      - 'v*' # Run only when a tag starting with 'v' is pushed

permissions: #<h>
  contents: write#<h>
  
# ...
```


</CodeFile>


### The Release Workflow


This workflow will be structured into two distinct, dependent **jobs**:

1. A **`build`** **job**: This job will essentially do the same thing as our previous CI job.  It will run in parallel across multiple operating systems, compiling our code, run the tests as a final quality check, package the artifacts using CPack, and store those packages for the next stage.
2. A **`release`** **job**: This job will only run _**after**_ all the parallel build jobs have succeeded. It will collect all the packages from the different platforms, create a single new Release on our GitHub repository, and upload each package as a downloadable asset to that release.

This two-job structure is a standard pattern in CI/CD. It separates the concerns of building (which is platform-specific and can be parallelized) from the concern of publishing (which is a single, central action).


<Pw>


## The `build` Job


Let's start by defining the `build` job in our new workflow file, which is substantively the same as our previous job.


In real projects, these jobs tend to deviate slightly, as release builds usually have different requirements from a CI build whose only purpose is to determine if a PR is safe to merge.


But, in our simple project, our release build can be exactly the same as our CI build:


<CodeFile path=".github/workflows/release.yml" status="New">


```yaml
name: Release

on:
  push:
    tags:
      - "v*"

permissions:
  contents: write

jobs:
  # This is identical to the job in ci.yml
  build:
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
    runs-on: ${{ matrix.os }}

    steps:
      - name: Check out code
        uses: actions/checkout@v4
      - name: Set up vcpkg
        uses: lukka/run-vcpkg@v11
      - name: Configure CMake
        run: cmake --preset release
      - name: Build project
        run: cmake --build --preset release
      - name: Run tests
        run: ctest --preset release

      - name: Package Libraries
        run: cpack --preset dev-zip
      - name: Upload Libraries
        uses: actions/upload-artifact@v4
        with:
          name: Greeter-Development-${{ matrix.os }}
          path: build/Greeter-*-Development.zip

      - name: Package Application
        if: matrix.os == 'windows-latest'
        run: cpack --preset windows-release-installer
      - name: Upload Application
        if: matrix.os == 'windows-latest'
        uses: actions/upload-artifact@v4
        with:
          name: Greeter-Installer-${{ matrix.os }}
          path: build/Greeter-*.msi
```


</CodeFile>


## The `release` Job


Once our build jobs are complete across all 3 platforms (`matrix.os`), we need one more job to actually create the release.  It gathers the artifacts generated from the previous jobs, and performs the public-facing actions of creating the release and uploading those assets.


The complete job is below, and we'll walk through its two steps in the next sections:


<CodeFile path=".github/workflows/release.yml" status="New">


```yaml
name: Release

on:
  push:
    tags:
      - "v*"

permissions:
  contents: write

jobs:
  build:
    # ... (unchanged from above)

  release:
    needs: build
    runs-on: ubuntu-latest

    steps:
      - name: Download all build artifacts
        uses: actions/download-artifact@v4
        with:
          path: artifacts
      - name: Create GitHub Release
        uses: softprops/action-gh-release@v2
        with:
          name: Release ${{ github.ref_name }}
          body: |
            Automated release of ${{ github.ref_name }}.
            Add a description to this draft
          files: |
            artifacts/**/*.zip
            artifacts/**/*.msi
          generate_release_notes: true
          append_body: true
          draft: true
          prerelease: false
```


</CodeFile>


The `needs: build` key establishes a dependency, guaranteeing that the `release` job will not start until all jobs in the `build` matrix have finished successfully.


We don't need a strategy matrix here, as we only want to create a single release for each run of this workflow.  We could use any runner that has the tools we need.  A Linux runner like `ubuntu-latest` tends to be the default choice for platform-agnostic tasks like this, as they're cheaper than Windows/macOS runners.


### Step 1: Download All Artifacts


The first step in our `release` job is to collect all the packages that the `build` jobs created. The `actions/download-artifact` action does this for us. With the default settings, it downloads all artifacts from the current workflow run:


```yaml
# In jobs: -> release: -> steps:
- name: Download all build artifacts
  uses: actions/download-artifact@v4
  with:
    path: artifacts
```


The `path: artifacts` input tells the action to place all downloaded artifacts into a single parent directory named `artifacts`. Inside, it will create subdirectories for each artifact, matching the names we gave them in the upload step. Our file system on the runner will look something like this:


```plain text
//<nh>
artifacts/
├─ package-windows-latest/
│  ├─ Greeter-1.0.0-win64.zip
│  └─ Greeter-1.0.0.msi
├─ package-ubuntu-latest/
│  └─ Greeter-1.0.0-Linux.zip
└─ package-macos-latest/
   └─ Greeter-1.0.0-Darwin.zip
```


The official documentation for `actions/download-artifact` is [available here](https://github.com/actions/download-artifact).


If we want to understand what's going on in our runner, we can add additional steps purely to provide status updates in our workflow log.  This can be particularly helpful when we need to debug things.


For example, after our `actions/download-artifact` step, we could list the contents of our `artifacts/` directory using a simple step that runs the [find](https://man7.org/linux/man-pages/man1/find.1.html) command:


```c++
- name: Display artifact structure
  run: find artifacts
```


### Step 2: Create the GitHub Release


With our artifacts downloaded and in our runner's `/artifacts` directory, we can create the actual release on GitHub. We'll use the `softprops/action-gh-release` action for this:


```yaml
# In jobs: -> release: -> steps:
- name: Create GitHub Release
  uses: softprops/action-gh-release@v2
  with:
    draft: true
    name: Release ${{ github.ref_name }}
    body: |
      Automated release of ${{ github.ref_name }}.
      Add a description to this draft
    append_body: true
    files: |
      artifacts/**/*.zip
      artifacts/**/*.msi
    generate_release_notes: true
    prerelease: false
```


The full documentation for `softprops/action-gh-release` is [available here](https://github.com/softprops/action-gh-release).  In our example, we used the following options:

- `draft`: Creating a draft release means our workflow won't immediately make our release public.  It gives us the opportunity to review and edit its output before we publish it for everyone to see.
- `name`: The title for our release.  The `github.ref_name` context variable contains just the tag name itself (e.g., `v1.0.0`), which we use to create a friendly title like "Release v1.0.0".
- `body`: This is where we would describe our release.  What new features did we add?  What bugs did we fix? In this case, we've just added some placeholder content, which we can replace using the GitHub UI whilst our release is still in draft.  We discuss ways to automate this later.
- `append_body`: This setting is relevant if we push the same tag multiple times, meaning this workflow would be updating a release that already exists.  Using `append_body` means the `body` of the updated release (the placeholder content in this workflow) won't overwrite the release notes we might have added added to the existing release.
- `files`: The list of files we want included in the release.  We can specify exact file names or, in this case, globbing patterns to select files that match a pattern.  The `artifacts/` subdirectory we're using here corresponds to the `path` we set in the previous step.
- `generate_release_notes`: GitHub includes the ability to automatically generate release notes, based on the PRs that have been merged to this branch since the previous release.  Documentation on how this works, and how we can configure it, is [available here](https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes).
- `prerelease`: GitHub includes the ability to flag releases as "prereleases".  This indicates to users that the release is not production ready, but provided if they want to test or experiment with upcoming features.  We're setting this to `false` here, but we can edit it through the GitHub UI once our draft release is created.

## The Full Automated Release in Action


Once we've committed and pushed our `release.yml` worfklow to our remote repository, drafting a new release is extremely quick.


When a version is deemed ready for release, we simply create and push a version tag:


```c++
//<ti>
git tag v1.1.0
```


```c++
//<ti>
git push origin v1.1.0
```


GitHub Actions detects the new tag and triggers the `Release` workflow.  We can see this from the "Actions" tab of our repository:


<Img file="github-release-1.png" alt="Screenshot showing the release workflow running" width="632" height="182" blurHash="L1RW0c0000~V5[?btSIq00xv^+%M" />


When it completes, a new, fully-populated draft release appears on the repository's "Releases" page, ready for us to review, edit and publish:


<Img file="github-release-2.png" alt="Screenshot showing an automatically generated draft release" width="572" height="525" blurHash="L0SPb40000~j#y00~W-@00V=o%xx" />


<Aside>


### Changelogs and Automating Release Notes


In this workflow, we're assuming our release notes will be edited manually, or that GitHub's automatically generated release notes (using `generate_release_notes` in the workflow, or the "Generate release notes" button in the UI) will be good enough.


However, investing a little more time and structure into keeping track of what has changed in our software over time is generally recommended.  The ["keep a changelog"](https://keepachangelog.com/) site explains many of the reasons why, and has some good recommendations on how this can be done.


Many teams also automate some of the processes around changelogs.  This might include automatically updating changelogs based on commits and merged pull requests, or automatically inserting the relevent parts of our changelog into the `body` of each release.


For projects built within the GitHub ecosystem, the [GitHub Actions marketplace](https://github.com/marketplace?type=actions) has many utilities to assist with this, such as [Release Changelog Builder](https://github.com/marketplace/actions/release-changelog-builder).


</Aside>


## Course Summary


Congratulations! You have reached the end of this course.


We began in **Chapters 1 and 2** by dissecting the fundamental C++ build process. We moved from raw compiler and linker commands to understanding the need for project organization and a build system.


In **Chapters 3 through 5**, we were introduced to CMake. We learned its core language - variables, lists, and control flow - and, most importantly, the modern, target-centric philosophy. We learned to think of our projects not as a list of files, but as a dependency graph of targets with properties.


**Chapters 6 through 9** taught us how to manage the complexities of real-world development. We handled different platforms, architectures, and build configurations. We learned how to integrate external dependencies using `find_package()` and `FetchContent`, and then introduced package managers like vcpkg and Conan. We also introduced CMake Presets as the primary way we issue commands, streamlining our workflow.


In **Chapters 10 through 13**, we moved beyond compilation to cover common production requirements. We integrated code generators with custom commands, created developer utilities with custom targets, and built a quality assurance pipeline with automated testing, memory sanitization, performance benchmarking, and static analysis.


Finally, in this chapter, we placed our code under version control with Git and built a complete Continuous Integration and Continuous Delivery (CI/CD) pipeline. We automated our builds, tests, packaging, and, in this final lesson, our releases.


A solid build system is the bedrock of any successful software project, and you are now equipped with the knowledge to build that foundation.  Thank you for taking this course!


</Pw>

Build Servers

Managing releases in a repository

Events that trigger workflows

Action for creating GitHub Releases

Action for uploading release assets

Git Basics - Tagging

Semantic Versioning 2.0.0

CI/CD Tutorial using GitHub Actions - Automated Testing & Automated Deployments

Master automated C++ deployment with this CMake and GitHub Actions tutorial. Learn the complete CI/CD workflow, from triggering a release on a Git tag push to automatically building, running CPack, and uploading your packaged installers and archives to a new GitHub Release.

Deployment with GitHub Releases

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Managing C++ Projects Using CMake