DevOps Practices

Feature-branch workflow (GitHub flow)

%%{init: {'gitGraph': {'rotateCommitLabel': false}}}%%
gitGraph
  commit id: "a"
  branch feature/17-waitlist
  commit id: "w1"
  commit id: "w2"
  checkout main
  branch feature/23-report
  commit id: "r1"
  checkout feature/17-waitlist
  commit id: "w3"
  checkout main
  merge feature/17-waitlist id: "PR 31"
  checkout feature/23-report
  commit id: "r2"
  checkout main
  merge feature/23-report id: "PR 32" tag: "v0.2.0"

Trunk-based development

%%{init: {'gitGraph': {'rotateCommitLabel': false}}}%%
gitGraph
  commit id: "t1"
  branch s1
  commit id: "x"
  checkout main
  merge s1 id: "PR 40"
  commit id: "t2"
  branch s2
  commit id: "y"
  checkout main
  merge s2 id: "PR 41"
  commit id: "t3" tag: "v0.2.0"

cmake_minimum_required(VERSION 3.28)
project(clubhub VERSION 0.1.0 LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
# compile_commands.json for editors and clang-tidy
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

# 1. core library: domain model and business rules
add_library(clubhub_core STATIC
  src/club.cpp
  src/event.cpp
  src/registration_service.cpp
  src/csv_event_repository.cpp)
target_include_directories(clubhub_core PUBLIC include)

# 2. command-line front end: only main() and argument parsing
add_executable(clubhub src/main.cpp)
target_link_libraries(clubhub PRIVATE clubhub_core)

# 3. unit tests with GoogleTest, downloaded at configure time
include(FetchContent)
FetchContent_Declare(googletest
  URL https://github.com/google/googletest/archive/refs/tags/v1.15.2.tar.gz)
# Windows/MSVC: use the same runtime library as our code
set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)
FetchContent_MakeAvailable(googletest)

enable_testing()
add_executable(clubhub_tests
  tests/event_test.cpp
  tests/registration_service_test.cpp)
target_link_libraries(clubhub_tests
  PRIVATE clubhub_core GTest::gtest_main)
include(GoogleTest)
gtest_discover_tests(clubhub_tests)

• PUBLIC include: whoever links clubhub_core also sees include/clubhub/*.hpp.
• enable_testing() switches on CTest; gtest_discover_tests registers every TEST(...) as a separate CTest test.
• FetchContent pins the dependency version in the file: every machine gets the same GoogleTest.

// tests/registration_service_test.cpp
#include <gtest/gtest.h>
#include "clubhub/registration_service.hpp"

TEST(RegistrationServiceTest, RejectsWhenEventIsFull) {
    // arrange: event with capacity 1, one student
    // act + assert: second student is rejected
}

// before: compiles, but hides two problems
int countRegistered(const std::vector<Registration>& regs,
                    const std::string& eventId,
                    bool includeWaitlist) {
    int n = 0;
    for (int i = 0; i < regs.size(); ++i) {
        if (regs[i].eventId() == eventId &&
            regs[i].status() == RegistrationStatus::Registered) {
            ++n;
        }
    }
    return n;
}

$ cmake --build build
registration_service.cpp:14:23: error: comparison of integer
  expressions of different signedness [-Werror=sign-compare]
registration_service.cpp:10:26: error: unused parameter
  'includeWaitlist' [-Werror=unused-parameter]

The unused flag suggests a forgotten feature: the waiting list was never counted. The warning found a requirement bug, not just a style issue.

// after: no unused flag, the types agree
// needs <algorithm>, <span>, <string_view>
std::size_t countRegistered(std::span<const Registration> regs,
                            std::string_view eventId) {
    return static_cast<std::size_t>(std::ranges::count_if(
        regs, [eventId](const Registration& r) {
            return r.eventId() == eventId &&
                   r.status() == RegistrationStatus::Registered;
        }));
}

# warnings are errors for OUR targets only, not for GoogleTest
if(MSVC)
  set(CLUBHUB_WARNINGS /W4 /WX)
  # MSVC calls std::getenv "unsafe" (C4996); it is standard C++
  add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
else()
  set(CLUBHUB_WARNINGS -Wall -Wextra -Wpedantic -Werror)
endif()
foreach(t IN ITEMS clubhub_core clubhub clubhub_tests)
  target_compile_options(${t} PRIVATE ${CLUBHUB_WARNINGS})
endforeach()

name: CI
on:
  push:
  pull_request:

jobs:
  build:
    name: build (${{ matrix.cc }})
    runs-on: ubuntu-latest
    strategy:
      # let both compilers finish even if one fails
      fail-fast: false
      matrix:
        include:
          - { cc: gcc, cxx: g++ }
          - { cc: clang, cxx: clang++ }
    env:
      CC: ${{ matrix.cc }}
      CXX: ${{ matrix.cxx }}
    steps:
      - uses: actions/checkout@v4
      - name: Configure
        run: cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
      - name: Build
        run: cmake --build build --parallel
      - name: Test
        run: ctest --test-dir build --output-on-failure
      - name: Package executable
        if: matrix.cc == 'gcc'
        run: tar -czf clubhub-linux-x64.tar.gz -C build clubhub
      - name: Upload artifact
        if: matrix.cc == 'gcc'
        uses: actions/upload-artifact@v4
        with:
          name: clubhub-linux-x64
          path: clubhub-linux-x64.tar.gz
          retention-days: 14

• Triggers: every push to any branch and every pull request.
• Matrix: two jobs, build (gcc) and build (clang). The variables CC and CXX tell CMake which compiler to use.
• Same commands as on your laptop: if CI fails, you can reproduce it locally.
• --output-on-failure prints the failing test's output in the log.
• Artifact: the GCC job keeps the executable for 14 days; the release in Topic 7 uses it.
• Badge in README.md: ![CI](https://github.com/ORG/REPO/actions/workflows/ci.yml/badge.svg)

# ---- stage 1: build and test with the full GCC toolchain ----
FROM gcc:14 AS build
# the Debian cmake in this image may be older than 3.28: fetch one
ARG CMAKE_VER=3.31.6
RUN base=https://github.com/Kitware/CMake/releases/download \
 && curl -fsSL "$base/v$CMAKE_VER/cmake-$CMAKE_VER-linux-$(uname -m).tar.gz" \
    | tar -xz --strip-components=1 -C /usr/local
WORKDIR /src
COPY . .
RUN cmake -S . -B build -DCMAKE_BUILD_TYPE=Release \
      -DCMAKE_EXE_LINKER_FLAGS="-static-libstdc++ -static-libgcc" \
 && cmake --build build --parallel \
 && ctest --test-dir build --output-on-failure

# ---- stage 2: small runtime image, no compiler inside ----
FROM debian:trixie-slim
RUN useradd --create-home clubhub
COPY --from=build /src/build/clubhub /usr/local/bin/clubhub
USER clubhub
WORKDIR /home/clubhub
ENV CLUBHUB_DATA_DIR=/home/clubhub/data
ENTRYPOINT ["clubhub"]
CMD ["--help"]

docker build -t clubhub:0.1.0 .
docker run --rm clubhub:0.1.0 --version
docker run --rm -v "$PWD/data:/home/clubhub/data" \
  clubhub:0.1.0 events list

• Multi-stage: stage 1 has compilers and sources (over 1 GB); stage 2 copies only the executable, so the final image is under 100 MB.
• -static-libstdc++: the C++ runtime is inside the binary, so the slim image does not need GCC's library.
• Runs as a normal user, data in a mounted folder: the container itself stays disposable.
• Add a .dockerignore with build/ and .git/.

DevSecOps means security is part of every stage, not a check at the end ("shift left"): the earlier a problem is found, the cheaper it is to fix.

# CMakeLists.txt, before add_library(): opt-in sanitizer build
option(CLUBHUB_SANITIZE "Build with ASan and UBSan" OFF)
if(CLUBHUB_SANITIZE AND NOT MSVC)
  add_compile_options(-fsanitize=address,undefined
                      -fno-omit-frame-pointer)
  add_link_options(-fsanitize=address,undefined)
endif()

// out of bounds: the sanitizer build catches what tests miss
const Registration& lastOnWaitlist(
        const std::vector<Registration>& waitlist) {
    // off by one: should be waitlist.back() (and check empty())
    return waitlist[waitlist.size()];
}

$ cmake -S . -B build-asan -DCLUBHUB_SANITIZE=ON
$ cmake --build build-asan && ctest --test-dir build-asan
ERROR: AddressSanitizer: heap-buffer-overflow ...

# secrets live in GitHub (Settings, Secrets), never in the YAML
- name: Send a test reminder
  env:
    SMTP_PASSWORD: ${{ secrets.SMTP_PASSWORD }}
  run: ./build/clubhub remind --dry-run

Here a "deployment" is a tagged release of the executable. Lead time runs from the first commit of a change to the release that contains it.

Deployment frequency
  8 releases / 4 weeks        = 2 per week

Lead time for changes (16 changes, sorted, hours)
  2 3 4 5 6 6 7 8 | 9 10 12 15 20 26 30 48
  median = (8 + 9) / 2        = 8.5 hours

Change failure rate
  2 failed / 8 releases       = 25 %

Time to restore service
  (3 h + 1 h) / 2 failures    = 2 hours