CI/CD pipeline для TypeScript: настройка с нуля на PythonLib

CI/CD pipeline для TypeScript: настройка с нуля — пошаговое руководство

Вы написали крутой проект на TypeScript. Код красивый, типы строгие, логика выверена. Но каждый раз, когда нужно залить обновление на сервер, вы вручную запускаете сборку, проверяете, не сломалось ли что-то, и молитесь, чтобы продакшен не упал. Знакомо?

Пора это изменить. CI/CD pipeline — это не магия для сеньоров с двадцатилетним стажем. Это инструмент, который автоматизирует рутину: линтинг, тесты, сборку и деплой. Один коммит в ветку — и всё летит в продакшен само, без нервотрёпки.

В этой статье мы с нуля настроим полноценный CI/CD pipeline для TypeScript-проекта. На примере GitHub Actions — бесплатного и мощного инструмента. Вы научитесь:

• Добавлять автоматический линтинг и форматирование
• Запускать юнит-тесты и проверять типы
• Собирать приложение и деплоить на удалённый сервер
• Избегать типичных ошибок при настройке CI/CD

Готовы? Погнали!

Почему CI/CD критически важен для TypeScript-проекта

TypeScript — это строго типизированный язык, который компилируется в JavaScript. На первый взгляд, это даёт иллюзию безопасности: если код скомпилировался, значит, он рабочий. Но на практике компиляция не ловит логические ошибки, проблемы с API или кривые зависимости.

CI/CD (Continuous Integration / Continuous Deployment) решает эту проблему:

• Автоматическая проверка: каждый коммит проходит через конвейер — линтинг, тесты, компиляция. Если что-то сломалось, вы узнаете об этом через минуту, а не через неделю.
• Единый стандарт: вся команда работает по одним правилам. Никто не забудет запустить тесты перед пушем.
• Быстрый деплой: больше никаких ручных команд на сервере. Один merge в main — и обновление уже на боевом сайте.

Для TypeScript CI/CD особенно важен, потому что ошибки типов могут проявиться только в runtime, если не настроить компиляцию правильно. Pipeline это предотвращает.

Шаг 1: Подготовка TypeScript-проекта

Прежде чем настраивать CI/CD, убедитесь, что проект готов к автоматизации. Вот минимальный набор:

• package.json с описанными скриптами
• tsconfig.json — конфиг TypeScript
• ESLint и Prettier — для единообразия кода
• Тесты (Jest, Vitest или Mocha)

Допустим, у вас есть простой проект. Структура может выглядеть так:

my-ts-project/
├── src/
│   ├── index.ts
│   └── utils.ts
├── tests/
│   └── utils.test.ts
├── .eslintrc.json
├── .prettierrc
├── tsconfig.json
├── package.json
└── README.md

Убедитесь, что в package.json прописаны скрипты:

{
  "scripts": {
    "lint": "eslint src/ tests/ --ext .ts",
    "format": "prettier --check src/ tests/",
    "type-check": "tsc --noEmit",
    "test": "jest",
    "build": "tsc",
    "start": "node dist/index.js"
  }
}

Теперь проект готов к CI/CD. Если чего-то не хватает — добавьте. Pipeline будет вызывать именно эти команды.

Шаг 2: Выбор CI/CD платформы

Вариантов много: Jenkins, GitLab CI, CircleCI, Travis CI. Но для новичков и небольших проектов GitHub Actions — лучший выбор:

• Встроен в GitHub — не нужно ничего настраивать отдельно
• Бесплатный лимит: 2000 минут в месяц (для приватных репозиториев)
• Огромная экосистема готовых actions
• Понятный YAML-синтаксис

Если ваш код лежит на GitLab — используйте GitLab CI (описание почти такое же). Но в этой статье работаем с GitHub.

Шаг 3: Создание CI/CD конвейера — первый файл

В корне проекта создайте папку .github/workflows/, а внутри — файл ci.yml. Название может быть любым, но расширение обязательно .yml.

Начнём с простого — проверим, что код линтится и компилируется:

name: CI Pipeline

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

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install dependencies
        run: npm ci

      - name: Run linter
        run: npm run lint

      - name: Check formatting
        run: npm run format

      - name: Type check
        run: npm run type-check

      - name: Run tests
        run: npm test

      - name: Build project
        run: npm run build

Разберём, что здесь происходит:

• on.push — pipeline запускается при пуше в main или develop
• on.pull_request — также при создании PR в main
• runs-on: ubuntu-latest — используем виртуальную машину с Ubuntu
• Каждый шаг — это либо action из маркетплейса (actions/checkout), либо shell-команда
• npm ci — чистая установка зависимостей (быстрее и надёжнее, чем npm install)

Когда вы запушите этот файл в репозиторий, GitHub автоматически создаст вкладку Actions, где будет виден процесс выполнения. Если какая-то проверка упадёт — вы получите уведомление.

Шаг 4: Добавляем кэширование для ускорения

Каждый раз скачивать все зависимости заново — долго. TypeScript-проекты с десятками пакетов могут грузиться 2-3 минуты. Добавим кэширование node_modules:

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Cache node_modules
        uses: actions/cache@v4
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'