Blender Addon Development Needs More DevOps

Source: Dev.to

Overview

Write test code and automate it.
Run tests on various versions of Blender to release with peace of mind.

• Individual developers who are (or want to be) developing Blender addons.
• People who want to ensure quality but don’t know how to introduce CI/CD.
• People tired of manual fixes and checks.
• People interested in CI/CD using GitHub Actions (this article applies a general CI/CD pipeline to Blender addon development).

There is plenty of literature detailing DevOps, so I’ll skip the deep dive. In short, it is considered a best practice in general software development. In this methodology, the development flow is represented as an infinite loop of the following phases:

The article focuses on the phases marked with ★: Code, Build, Test, and Release.

The Problem

Blender 5 was officially released last month. I installed the beta version of 5 and about 30 addons (both paid and free). Many of them spewed errors. Even after the official release, several addons still lack working releases. When an addon’s description says “4.2 and later supported” but it fails in Blender 5, users are left wondering whether to wait or fix it themselves.

A simple CI setup that runs even a single pass could detect basic compatibility errors. Maintainers could then temporarily declare Blender 5 out of support scope or explicitly end support. If the maintainer has disappeared, there’s nothing to be done.

When examining repositories of various sizes, the culture of testing in the Blender addon ecosystem appears weaker than in other software development areas. While official‑like projects often have automated tests and delivery pipelines, many individual developer repositories—​even popular ones—​lack any test automation. Manual test procedures are often missing, making it hard to submit confident PRs because potential side effects are unknown. Large addons tend to become bloated as they respond to feature requests, further complicating maintenance.

The root cause seems to be that common practices from general software development haven’t permeated the Blender addon community. This article proposes a method that can be adopted directly.

A DevOps‑Ready Addon Example: SavePoints

I recently released my first addon, SavePoints, on Blender Extensions. It saves .blend files with thumbnails and notes, and performs periodic auto‑saves. The addon was built with DevOps in mind, serving as a template.

• Extension page:

Goals for Maintainability

1. Testability – isolate logic for unit testing.
2. CI compatibility – ensure the addon runs in a headless environment (-b flag).
3. Clear separation – keep Blender‑specific code minimal.

Headless Environment

A headless environment runs Blender without a GUI:

blender -b -P my_script.py

Reference:

Implementation Details

Thin Operator Layer

operators.py contains only the UI glue. Core processing lives in core.py and does not depend on bpy.

# operators.py
class SAVEPOINTS_OT_delete(bpy.types.Operator):
    # ...
    def execute(self, context):
        # The actual processing calls a function in core.py
        delete_version_by_id(item.version_id)
        return {'FINISHED'}

# core.py
def delete_version_by_id(version_id: str) -> None:
    # Standard Python logic (shutil, json, etc.) – no bpy usage
    ...

This separation allows unit tests to run without launching Blender.

Prefer bpy.data Over bpy.ops

Rule of thumb: Use bpy.data whenever possible; fall back to bpy.ops only when absolutely necessary. bpy.ops simulates user actions and requires a proper UI context, which often fails in CI (poll errors).

Guard Clauses for Headless Mode

When capturing a thumbnail with OpenGL, headless mode lacks a window. The code catches the exception and skips thumbnail generation:

def capture_thumbnail(context: bpy.types.Context, thumb_path: str) -> None:
    try:
        if context.window_manager.windows:
            bpy.ops.render.opengl(write_still=True)
            # ... save thumbnail ...
        else:
            pass  # Skip in headless mode
    except Exception as e:
        print(f"Thumbnail generation failed: {e}")

This adds environment‑dependent branching but prevents CI crashes.

Testing Strategy

I split tests into two layers for cost‑effectiveness.

Logic Tests

• Tools: pytest + fake-bpy-module
• Scope: Verify pure Python logic (path handling, data calculations, etc.) without launching Blender.
• Frequency: Run on every commit locally and in CI.

End‑to‑End (E2E) Tests

• Tools: Launch actual Blender in headless mode and run the addon.
• Scope: Validate that the addon interacts correctly with the Blender API.
• Frequency: Run occasionally during development and on key CI events (e.g., merge to main).

Because most compatibility issues stem from API changes, E2E tests are crucial for catching breakages when Blender updates.

Setting Up CI with GitHub Actions

A minimal workflow that runs both test layers:

name: CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        blender-version: [ "3.6", "4.0", "5.0" ]

    steps:
      - uses: actions/checkout@v3

      - name: Install Blender
        run: |
          sudo add-apt-repository ppa:thomas-schiex/blender
          sudo apt-get update
          sudo apt-get install blender=${{ matrix.blender-version }}

      - name: Install Python dependencies
        run: |
          python -m pip install --upgrade pip
          pip install pytest fake-bpy-module

      - name: Run Logic Tests
        run: pytest tests/logic

      - name: Run E2E Tests
        run: |
          blender -b -P tests/e2e/run_tests.py

Adjust the Blender installation step to match your platform. The workflow builds a clean ZIP (the Build phase) and can publish it as a release artifact (the Release phase).

Conclusion

By treating Blender addon development like any other software project—splitting code, writing unit and E2E tests, and automating the pipeline with CI—you can:

• Detect compatibility issues early (especially across Blender versions).
• Reduce manual testing effort.
• Provide maintainers and contributors with confidence when submitting PRs.

Adopting these practices brings the Blender addon ecosystem closer to modern DevOps standards, leading to more stable and maintainable addons.