CI/CD 101 для AEC-фахівців

Що таке CI/CD і чому це важливо для AEC?

Якщо ви чули, як розробники говорять про “пайплайни” та “автоматизовані деплойменти” і відчували, що вони говорять іншою мовою, ви не самотні. CI/CD🔁CI/CDAutomated build, test, and deployment pipelines.View in glossary звучить технічно, але концепція напрочуд проста — і неймовірно актуальна для AEC-процесів.

CI/CD означає:

• Continuous Integration (CI): Автоматичне тестування та валідація змін по мірі їх внесення
• Continuous Deployment (CD): Автоматичне переміщення перевіреної роботи туди, де вона потрібна

У програмному забезпеченні це означає, що код потрапляє з ноутбука розробника на продакшн-сервери автоматично. В AEC це означає, що моделі потрапляють з комп’ютера проєктувальника до BIM 360🔵BIM 360Legacy Autodesk construction platform (predecessor to ACC).View in glossary/ACC🏗️ACCAutodesk's construction management platform.View in glossary, транслюються та оповіщують команду — автоматично.

Таємна зброя софтверної індустрії

Софтверні компанії десятиліття тому зрозуміли, що ручні процеси створюють вузькі місця. Щоразу, коли людині потрібно:

• Пам’ятати щось зробити
• Клікати через вебінтерфейс
• Надіслати email-оповіщення
• Перевірити статус

…з’являється можливість для:

• Забування
• Помилок
• Затримок
• Перемикання контексту

Рішення? Автоматизувати все, що можна автоматизувати.

Ось як виглядає типовий CI/CD-пайплайн у розробці:

Кожен крок після початкового коміту відбувається автоматично. Розробник пушить код і йде. Якщо щось не вдається, він отримує оповіщення. Якщо все вдалося, код вже у продакшні.

Переклад CI/CD на мову AEC

Тепер перенесемо це на AEC-процеси. Ось як може виглядати автоматизований BIM🏛️BIMIntelligent 3D model-based design for buildings.View in glossary-пайплайн:

Досвід проєктувальника:

1. Зберегти модель
2. Все

Все інше відбувається у фоновому режимі. Команда отримує оповіщення, коли модель готова. Якщо щось не вдається, проєктувальник дізнається одразу, а не через кілька годин.

Ключові концепції CI/CD для AEC

1. Тригери

Тригер — це те, що запускає автоматизацію. У розробці це зазвичай коміт коду. В AEC це може бути:

• Збереження файлу у відстежувану папку
• Пуш до Git-репозиторію
• Запланований час (нічна обробка)
• Натискання кнопки вручну (для важливих релізів)

# Example: Trigger on file changes
on:
  push:
    paths:
      - 'models/**/*.rvt'
      - 'models/**/*.dwg'

2. Джоби та кроки

Пайплайн складається з джобів, і кожен джоб містить кроки:

jobs:
  process-model:
    steps:
      - name: Upload to APS
        run: raps object upload my-bucket model.rvt

      - name: Start Translation
        run: raps translate start $URN --wait

      - name: Notify Team
        run: slack-notify "Model ready for review"

3. Змінні середовища та секрети

Конфіденційна інформація (API🔌APIInterface for software components to communicate.View in glossary-ключі, паролі) зберігається як секрети, а не в коді пайплайну:

env:
  APS_CLIENT_ID: ${{ secrets.APS_CLIENT_ID }}
  APS_CLIENT_SECRET: ${{ secrets.APS_CLIENT_SECRET }}

Це означає, що ви можете поділитися конфігурацією пайплайну, не розкриваючи облікові дані.

4. Артефакти

Артефакти — це результати вашого пайплайну, те, що ви хочете зберегти:

• Трансльовані файли моделей
• Згенеровані мініатюри
• Звіти з вилученими властивостями
• Результати QA/QC

- name: Save Artifacts
  uses: actions/upload-artifact@v4
  with:
    name: model-outputs
    path: |
      outputs/thumbnail.png
      outputs/properties.json

Ваш перший AEC-пайплайн

Створимо простий пайплайн, який:

1. Визначає зміни моделі Revit🏠RevitAutodesk's BIM software for architecture and construction.View in glossary
2. Завантажує її до APS☁️APSAutodesk Platform Services - cloud APIs for CAD/BIM automation.View in glossary
3. Транслює у SVF2🚀SVF2Current APS viewing format (improved performance).View in glossary
4. Оповіщує команду

Передумови

• GitHub-репозиторій для моделей
• Обліковий запис Autodesk Platform Services
• Встановлений RAPS🌼RAPSRust CLI for Autodesk Platform Services.View in glossary CLI💻CLIText-based interface for running commands.View in glossary

Пайплайн

Створіть .github/workflows/model-pipeline.yml:

name: Model Processing Pipeline

on:
  push:
    paths:
      - 'models/**/*.rvt'

jobs:
  process:
    runs-on: ubuntu-latest

    steps:
      # 1. Get the code
      - name: Checkout
        uses: actions/checkout@v4

      # 2. Install RAPS
      - name: Install RAPS CLI
        run: |
          curl -fsSL https://rapscli.xyz/install.sh | sh
          echo "$HOME/.cargo/bin" >> $GITHUB_PATH

      # 3. Authenticate
      - name: Login to APS
        env:
          APS_CLIENT_ID: ${{ secrets.APS_CLIENT_ID }}
          APS_CLIENT_SECRET: ${{ secrets.APS_CLIENT_SECRET }}
        run: raps auth login

      # 4. Process changed models
      - name: Process Models
        run: |
          # Find changed .rvt files
          for model in $(git diff --name-only HEAD~1 HEAD | grep '\.rvt$'); do
            echo "📦 Processing $model..."

            # Upload
            raps object upload project-bucket "$model"

            # Get URN
            URN=$(raps object urn project-bucket "$model")

            # Translate and wait
            raps translate start $URN --format svf2 --wait

            echo "✅ $model processed successfully"
          done

      # 5. Notify team
      - name: Notify Slack
        if: success()
        run: |
          curl -X POST ${{ secrets.SLACK_WEBHOOK }} \
            -H 'Content-Type: application/json' \
            -d '{"text": "🏗️ Model pipeline completed successfully!"}'

Налаштування секретів

У вашому GitHub-репозиторії:

1. Перейдіть до Settings → Secrets and variables → Actions
2. Додайте ці секрети:
   • APS_CLIENT_ID — Ваш Autodesk app client ID
   • APS_CLIENT_SECRET — Ваш Autodesk app client secret🔒SecretEncrypted sensitive configuration value.View in glossary
   • SLACK_WEBHOOK — Ваш Slack webhook🪝WebhooksEvent notifications sent to your application.View in glossary URL (необов’язково)

Типові патерни пайплайнів для AEC

Патерн 1: Нічна обробка

Обробка всіх моделей щоночі:

on:
  schedule:
    - cron: '0 2 * * *'  # 2 AM every day

Патерн 2: Ручне затвердження

Вимога затвердження перед обробкою:

jobs:
  approve:
    runs-on: ubuntu-latest
    environment: production  # Requires approval in GitHub settings
    steps:
      - run: echo "Approved for processing"

  process:
    needs: approve
    # ... processing steps

Патерн 3: Кілька середовищ

Різні пайплайни для різних цілей:

jobs:
  process:
    runs-on: ubuntu-latest
    steps:
      - name: Set Environment
        run: |
          if [[ "${{ github.ref }}" == "refs/heads/main" ]]; then
            echo "ENV=production" >> $GITHUB_ENV
            echo "BUCKET=prod-models" >> $GITHUB_ENV
          else
            echo "ENV=staging" >> $GITHUB_ENV
            echo "BUCKET=staging-models" >> $GITHUB_ENV
          fi

Патерн 4: Якісні ворота

Зупинка обробки при невдалій валідації:

- name: Validate Model
  run: |
    # Check file size
    SIZE=$(stat -f%z "$MODEL_PATH")
    if [ $SIZE -gt 500000000 ]; then
      echo "❌ Model exceeds 500MB limit"
      exit 1
    fi

    # Check for required parameters
    raps model metadata extract $URN --check-required

Моніторинг та налагодження

Перегляд запусків пайплайну

У GitHub:

1. Перейдіть до вашого репозиторію
2. Натисніть на вкладку “Actions”
3. Побачите всі запуски пайплайну зі статусом

Налагодження збоїв

Коли щось не вдається:

1. Натисніть на невдалий запуск
2. Розгорніть невдалий крок
3. Прочитайте повідомлення про помилку
4. Виправте та запушьте знову

Додавання оповіщень

Отримуйте оповіщення при збоях:

- name: Notify on Failure
  if: failure()
  run: |
    curl -X POST ${{ secrets.SLACK_WEBHOOK }} \
      -H 'Content-Type: application/json' \
      -d '{"text": "❌ Pipeline failed! Check GitHub Actions for details."}'

ROI від CI/CD для AEC

Порахуємо:

При ставці $75/годину це $52 000/рік на одного члена команди у відновленій продуктивності.

Наступні кроки

1. Почніть з малого: Автоматизуйте один болючий процес
2. Вимірюйте: Відстежуйте зекономлений час
3. Ітеруйте: Додавайте більше автоматизації по мірі набуття впевненості
4. Діліться: Навчайте свою команду

Інструменти існують. Патерни перевірені. Питання в тому: коли ви почнете?

Це друга стаття серії “DevOps for Design”. ← Попередня: The Manual Tax | Наступна: Zero-Click Releases →

Готові автоматизувати свої APS-процеси? Почніть з RAPS або зв’яжіться зі мною в LinkedIn.