Introduction to CI/CD and CMake

What is CI/CD

• CI - Continuous Integration
  • Improve: Source Code Delivery, Build, Test (Unit and Integration)
• CD - Continuous Delivery/ Deployment
  • Improve: Deployment, User acceptance testing,

CI/CD Tools

• Jenkins
  • Open-source mostly focused on CI
• Bamboo
  • A CI tool and part of JIRA & bitbucket
• CircleCI
  • Good for cross-platform environments (e.g., mobile apps)
• Gitlab CI/CD pipelines
  • Integrates with gitlab, various types of pipelines (basic, DAG, multi-project, etc.)

CI/CD Pipeline Best Practices:

• Pipelines could change depending on the development process, teams, production, CI/CD tools, etc.
• Write the pipeline and determine which part can be automated (a lot of it)
• Some stages are necessary in your pipeline, e.g., testing, peer code review (pull requests), etc.
• Separate the stage environments for better management (e.g., use a separate branch on git)
• Devise metrics for transitioning to CD (e.g. test coverage)

Revisit Branching Strategies in git

Branching strategy is a set of rules an policies for creating branches, maintaining them, and merging them to optimize the agility of teams and quality of code

Branching Strategies - GitFlow

• Master: main stable branch
• Develop: main branch for development
• Feature: for new features branched off develop
• Release: for production
• release (testing), merged back to master & develop
• Hotfix: for fixing bugs

GitFlow Pros and Cons

Pros:

• Allows parallel development, production, and fixing bugs
• Organizes the work of the developers naturally
• Allows handling multiple versions (not crucial if using git tags)

Cons:

• Complicated pipelines due to multiple merges
• If a test fails in the master branch it could be difficult to pinpoint the branch that hosts the issue
• Not recommended for amateur teams & for agile CI/CD

Branching Strategies - Github Flow

• Master branch: stable deployable branch
• Feature branches: temporary branches off the master branch to isolate the work of developers. Merged back into the master branch

Github Flow Pros and Cons

Pros:

• Much simpler compared to gitflow
• Allows for agile development and short production cycles
• Allows for fast feedback and easier debugging
• Ideal for small teams

Cons:

• Not suitable for handling multiple versions
• More likely to have an unstable master branch due to lack of develop/release branches (requires good testing pipelines before merging into the master branch)
• Number of merge conflicts grows with bigger teams and slows CI/CD

Branching Strategies - Gitlab Flow

(Middle Ground between Github Flow and Git Flow)

• Master branch: act as the develop branch
• Environment branches: the middle branches before merging to the production branch (staging/pre-production)
• Production branch: the ‘downstream’ stable code in use

Gitlab Flow Pros and Cons

Pros:

• Provides proper isolation between production and development
• Allows for staging environments (testing vs production)
• Great for when the timing of the releases is not under control (iOS)

Cons:

• Requires proper setup of the staging & QA pipelines
• Could be complicated with large teams

Branching Strategies - Trunk-based Development

• Master branch: core “trunk” that received quick and frequent merges (e.g., once a day). Stable anytime
• Feature Branches: short-lived temporary branches that are merged quickly into the trunk (sometimes implemented with flags)

Trunk-based Development Pros and Cons

Pros:

• Avoids merge conflicts by forcing developers to integrate their changes quickly
• Encourages CI/CD due to faster integration and releases
• Enhances collaboration between the team members

Cons:

• Suited for more senior teams
• Requires careful management of features and multiple versions
• Requires streamlining of merging and integration phases (massive pipelines)

Building Systems

Assume we have the following files:

• A file containing the class complex: complex.hpp
• A file containing the class calVar: calc.hpp
• A file containing the function parseLine: parse.cpp
• A file containing the main function: calculator.cpp

To compile the entire project:

g++ -o calc.out main.cpp parse.cpp

What if the directory structure of the project changed?

• ./PROJECT/ : the project directory
• ./PROJECT/include/ : header files
• ./PROJECT/src/ : the source code files
• ./PROJECT/bin/ : the executables

Compiling from the project directory:

g++ -o bin/calc.out src/main.cpp src/parse.cpp -I include

• What if the dependencies changes? For example, using different versions of g++
• If we change any of the files means compiling and linking all the files again
  • We only need to recompile the changed file
• Is there a way to streamline the building process in an efficient way?

Building Systems Tool

A software build system is the usage of a set of tools for building software applications

• Putting together several parts of the software efficiently
• Automating the build as a pipeline in our CI/CD
• Each part might be in a different programming language
• We may want to build is for different target machines (execution environment)

GNU-MAKE

Uses a Makefile to issues commands what pieces need to be [re]compiled and [re]linked.

What is a Makefile: a set of rules in the following format:

target ... : prerequisites ...
             recipe
						 ... 
						 ...

A makefile example

SRC = ./src/
INE = ./include/
BIN = ./bin/
CFLAG = -I

calc : $(SRC)calculator.cpp $(SRC)parse.cpp
					g++ -o $(BIN)calc.out $(SRC)calculator.cpp $(SRC)parse.cpp $(CFLAG)$(INC)
parse:
					g++ -o $(BIN)parse.o $(SRC)parse.cpp
parseTest: $(SRC)parse.cpp
					g++ -o $(BIN)parseTest.out $(SRC)parseTest.cpp $(SRC)parse.cpp

clean:
			rm $(SRC)*.o

To run them:

make
make calc
make parse

Another makefile example

calc.out: main.cpp parse.cpp
      g++ -o calc.out main.cpp parse.cpp -I.
# Using variables
CXX=g++
CFLAGS=-I.
calc.out: main.o parse.o
      $(CXX) -o calc.out main.o parse.o $(CFLAGS)
# Adding dependencies
DEPS = calc.hpp
CXX=g++
CFLAGS=-I.\include
calc.out: main.o parse.o $(DEPS)
       $(CXX) -o calc.out main.o parse.o $(CFLAG)
# Cleaning
clean:
rm *.o
# Better cleaning!
.PHONY: clean
clean:
			rm *.o

But Makefiles are tedious to make.

A better way is to use a Build System Generator:

• A tool that generates native build system files
  • E.g. CMake

CMake

It uses CMake scripting (declarative) language to describe the build

The developer edits the CMakeLists.txt

• invokes CMake but should never edit the generated files by CMake (e.g., Makefiles)

CMake does not compile (remember it is a build system generator), the underlying build system (e.g., make) does, and you have to run that explicitly after running CMake

CMakeLists.txt Example

cmake_minimum_required(VERSION 3.10)
project(calc)
include_directories(include)
file(GLOB SOURCES "src/*.cpp")
set(CMAKE_CXX_STANDARD 11)
add_executable(calc ${SOURCES})

Another example

# put the minimum required version for CMake
cmake_minimum_required(VERSION 3.10)

# information about your project.
# Only name (first argument) is mandatory the rest is optional
project(calc
  VERSION 0.1
  DESCRIPTION "A complex calculator that just adds!"
  LANGUAGES CXX
)

# Sets the version of the C++ compiler
set(CMAKE_CXX_STANDARD 11)

# the include directory
include_directories(include)

# Add the source files to SOURCES as a variable
file(GLOB SOURCES "src/*.cpp")

# Adds the executable
# the first argument is the name of the executable file
add_executable(calc ${SOURCES})

https://github.com/TheErk/CMake-tutorial

https://vinesmsuic.github.io/cmake-tuto/