CI/CD: Faster, Easier Development

ARC Collaborations Hour

Patrick J. Roddy
DevOps Subgroup

2024-09-10

Scan to view the slides

CI/CD vs DevOps

Continuous Integration (CI)

  • Definition: Practice of frequently merging code changes into a central repository
  • Goal: Detect and address integration issues early
  • Key practices:
    • Automated building and testing of code
    • Frequent code commits
    • Rapid feedback on code quality

Continuous Delivery/Deployment (CD)

  • Continuous Delivery:
    • Automatically prepare code for release to production
    • Manual decision for final deployment
  • Continuous Deployment:
    • Automatically deploy code changes to production
    • No manual intervention required
  • Goal: Reduce time between writing code and its use in production

DevOps

I previously gave talk on a general overview of DevOps https://paddyroddy.github.io/talks/devops-an-introduction

DevOps

  • Definition: Cultural and professional movement that aims to unify software development (Dev) and IT operations (Ops)
  • Scope: Broader, encompasses entire software delivery
  • Key aspects:
    • Cultural change: Breaking down silos between teams
    • Automation: Throughout the entire software lifecycle
    • Measurement: Continuous monitoring and feedback
    • Sharing: Increased collaboration and shared responsibility

Relationship Between CI/CD & DevOps

  • CI/CD are practices within the broader DevOps philosophy
  • DevOps often employs CI/CD as key tools, but also includes:
    • Infrastructure as Code
    • Configuration Management
    • Monitoring and Logging
    • Incident Response

Key Differences

  • Scope:
    • CI/CD: Focused on automating specific parts of the development pipeline
    • DevOps: Holistic approach to the entire software delivery lifecycle
  • Cultural Aspect:
    • CI/CD: Primarily technical practices
    • DevOps: Emphasises cultural change and cross-functional collaboration

Key Differences

  • Goals:
    • CI/CD: Faster, more reliable software releases
    • DevOps: Improved overall organisational efficiency and product quality

While CI/CD are crucial components of DevOps, CI/CD alone isn’t DevOps. True DevOps requires a broader cultural and operational shift.

GitHub Actions

What Are GitHub Actions?

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.

  1. Workflows: Automated processes that you set up in your repository to build, test, package, release, or deploy your project.
  2. Jobs: A set of steps that execute on the same runner. By default, a workflow with multiple jobs will run those jobs in parallel.

What Are GitHub Actions?

  1. Steps: An individual task that can run commands or actions. Each step in a job executes on the same runner, allowing the actions in that job to share data with each other.
  2. Actions: Standalone commands that are combined into steps to create a job. Actions are the smallest portable building block of a workflow.
  3. Runners: A server that runs your workflows when they’re triggered. Each runner can run a single job at a time.

Workflow Syntax

Workflows are defined in YAML files in the .github/workflows directory of your repository. Here’s a basic structure:

name: CI

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run a one-line script
        run: echo Hello, world!

Example Uses

  • Continuous Integration: Automatically build and test your code every time you push to your repository or open a pull request.
  • Continuous Deployment: Automatically deploy your application to staging or production environments when specific conditions are met.
  • Automated Testing: Run your test suite on multiple platforms and versions of your programming language.

Example Uses

  • Code Linting and Formatting: Enforce coding standards across your project.
  • Issue and PR Management: Automatically label, close, or comment on issues and pull requests based on certain conditions.
  • Scheduled Tasks: Run tasks at specific times, like daily backups or weekly report generation.

Benefits

  • Integrated with GitHub: No need for external CI/CD tools.
  • Matrix Builds: Easily test across multiple operating systems and runtime versions.
  • Community Actions: Reuse and share actions from the GitHub community.
  • Flexible: Build custom workflows for any project or git repository.

Best Practices

  • Use secrets for sensitive information
  • Keep your actions versioned
  • Minimise workflow run time by using build matrices and caching
  • Use status badges in your README to show your workflow status

Avoiding Duplication

Reusable workflows Composite actions
A YAML file, very similar to any standard workflow file An action containing a bundle of workflow steps
Each reusable workflow is a single file in the .github/workflows directory of a repository Each composite action is a separate repository, or a directory, containing an action.yml file and, optionally, other files

Avoiding Duplication

Reusable workflows Composite actions
Called by referencing a specific YAML file Called by referencing a repository or directory in which the action is defined
Called directly within a job, not from a step Run as a step within a job
Can contain multiple jobs Does not contain jobs

Avoiding Duplication

Reusable workflows Composite actions
Each step is logged in real-time Logged as one step even if it contains multiple steps
Can connect a maximum of four levels of workflows Can be nested to have up to 10 composite actions in one workflow
Can use secrets Cannot use secrets

Demos

https://www.menti.com: 5135 9261