Blender Addon 개발에 DevOps가 더 필요함

Source: Dev.to

Overview

테스트 코드를 작성하고 자동화하세요.
여러 버전의 Blender에서 테스트를 실행하여 안심하고 릴리스할 수 있습니다.

• Blender 애드온을 개발하고 있는(또는 개발하고 싶은) 개인 개발자.
• 품질을 보장하고 싶지만 CI/CD 도입 방법을 모르는 사람들.
• 수동 수정 및 검증에 지친 사람들.
• GitHub Actions를 이용한 CI/CD에 관심 있는 사람들(이 글은 일반적인 CI/CD 파이프라인을 Blender 애드온 개발에 적용합니다).

DevOps에 관한 문헌은 풍부하므로 깊게 파고들지는 않겠습니다. 요컨대, 일반 소프트웨어 개발에서 권장되는 베스트 프랙티스입니다. 이 방법론에서는 개발 흐름을 다음 단계들의 무한 루프로 표현합니다:

이 글은 ★ 로 표시된 단계, 즉 Code, Build, Test, Release 에 초점을 맞춥니다.

The Problem

Blender 5가 지난 달 공식 출시되었습니다. 저는 5의 베타 버전을 설치하고 약 30개의 애드온(유료·무료 모두)을 사용해 보았습니다. 대부분이 오류를 발생시켰습니다. 공식 출시 이후에도 여전히 작동 가능한 릴리스를 제공하지 못하는 애드온이 다수 존재합니다. 애드온 설명에 “4.2 이후 지원”이라고 적혀 있지만 Blender 5에서 실패한다면, 사용자는 기다려야 할지 직접 고쳐야 할지 고민하게 됩니다.

단 한 번이라도 실행되는 간단한 CI 설정만으로도 기본적인 호환성 오류를 감지할 수 있습니다. 유지보수자는 일시적으로 Blender 5를 지원 범위에서 제외하거나 명시적으로 지원을 종료할 수 있습니다. 유지보수자가 사라졌다면 할 수 있는 일이 없습니다.

다양한 규모의 레포지토리를 살펴보면, Blender 애드온 생태계의 테스트 문화가 다른 소프트웨어 개발 분야에 비해 약한 편입니다. 공식 프로젝트와 유사한 경우는 자동화된 테스트와 배포 파이프라인을 갖추고 있지만, 많은 개인 개발자 레포지토리—심지어 인기 있는 레포지토리조차—테스트 자동화가 전혀 없습니다. 수동 테스트 절차가 부족해 잠재적인 부작용을 알 수 없으므로 자신감 있게 PR을 제출하기 어렵습니다. 큰 애드온은 기능 요청에 따라 비대해져 유지보수가 더욱 복잡해집니다.

근본 원인은 일반 소프트웨어 개발에서의 일반적인 관행이 Blender 애드온 커뮤니티에 충분히 퍼지지 않았기 때문인 것으로 보입니다. 이 글에서는 바로 적용할 수 있는 방법을 제안합니다.

A DevOps‑Ready Addon Example: SavePoints

저는 최근 Blender Extensions에 첫 번째 애드온 SavePoints 를 공개했습니다. 이 애드온은 썸네일과 메모가 포함된 .blend 파일을 저장하고, 주기적인 자동 저장을 수행합니다. DevOps를 염두에 두고 제작했으며, 템플릿 역할을 합니다.

• Extension page:

Goals for Maintainability

1. Testability – 단위 테스트를 위한 로직 분리.
2. CI compatibility – 애드온이 헤드리스 환경(-b 플래그)에서도 동작하도록 보장.
3. Clear separation – Blender‑특화 코드를 최소화.

Headless Environment

헤드리스 환경은 GUI 없이 Blender를 실행합니다:

blender -b -P my_script.py

Reference:

Implementation Details

Thin Operator Layer

operators.py 는 UI 연결 역할만 담당합니다. 핵심 로직은 core.py 에 위치하며 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
    ...

이러한 분리 덕분에 Blender를 실행하지 않고도 단위 테스트를 수행할 수 있습니다.

Prefer bpy.data Over bpy.ops

Rule of thumb: 가능한 한 bpy.data 를 사용하고, 절대적으로 필요할 때만 bpy.ops 로 대체합니다. bpy.ops 는 사용자 동작을 시뮬레이션하고 적절한 UI 컨텍스트가 필요하기 때문에 CI에서 자주 실패합니다(폴링 오류).

Guard Clauses for Headless Mode

OpenGL 로 썸네일을 캡처할 때 헤드리스 모드에서는 창이 존재하지 않습니다. 코드는 예외를 잡아 썸네일 생성을 건너뛰게 합니다:

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}")

이렇게 하면 환경에 따라 분기 로직이 추가되지만 CI 충돌을 방지할 수 있습니다.

Testing Strategy

비용 효율성을 위해 테스트를 두 계층으로 나누었습니다.

Logic Tests

• Tools: pytest + fake-bpy-module
• Scope: Blender를 실행하지 않고 순수 Python 로직(경로 처리, 데이터 계산 등)을 검증.
• Frequency: 매 커밋마다 로컬 및 CI에서 실행.

End‑to‑End (E2E) Tests

• Tools: 실제 Blender를 헤드리스 모드로 실행하고 애드온을 구동.
• Scope: 애드온이 Blender API와 올바르게 상호 작용하는지 검증.
• Frequency: 개발 중 가끔, 주요 CI 이벤트(예: main 으로 병합) 시 실행.

대부분의 호환성 문제는 API 변경에서 비롯되므로, Blender 업데이트 시 파손을 잡아내는 데 E2E 테스트가 필수적입니다.

Setting Up CI with GitHub Actions

두 테스트 계층을 모두 실행하는 최소 워크플로우 예시:

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

Blender 설치 단계는 사용 중인 플랫폼에 맞게 조정하세요. 워크플로우는 깨끗한 ZIP 파일(Build 단계)을 생성하고, 이를 릴리스 아티팩트(Release 단계)로 배포할 수 있습니다.

Conclusion

Blender 애드온 개발을 다른 소프트웨어 프로젝트와 동일하게 다루어—코드를 분리하고, 단위 및 E2E 테스트를 작성하며, CI로 파이프라인을 자동화함으로써 다음을 달성할 수 있습니다:

• 특히 Blender 버전 간 호환성 문제를 조기에 감지.
• 수동 테스트 작업을 감소.
• 유지보수자와 기여자가 PR을 제출할 때 자신감을 제공.

이러한 관행을 채택하면 Blender 애드온 생태계가 현대 DevOps 표준에 가까워져 보다 안정적이고 유지보수가 쉬운 애드온을 만들 수 있습니다.