Что такое Continuous Integration (CI)?

Слушай, а вот этот ваш Continuous Integration, он же CI... Ну, непрерывная интеграция, блядь. Это ж не какая-то космическая хуйня, а просто нормальная практика, чтобы не было как всегда.

Представь: сидит команда, пилит фичу. Каждый в своей ветке, как крот в норе, хуярит код. И вот, чтобы потом, через месяц, не вылезти на свет божий и не обнаружить, что твой кусок нихуя не стыкуется с тем, что написал Васек, и всё это надо перепиливать с мясом — придумали эту самую CI.

Суть проще пареной репы: ты закоммитил свои изменения в общую ветку — и сразу, блядь, запускается автоматом целая кухня проверок. Собирается проект, прогоняются тесты, линтер прёт по коду. Если где-то косяк — тебе сразу же, сию секунду, прилетает оповещение: «Э, дружок-пирожок, ты тут хуйню смёрджил, иди чини». Это ж волшебство, ёпта! Раньше бы неделю искали, кто сломал продакшн, а теперь — раз, и виноватый найден.

Зачем это всё, спросишь? Да похуй, спроси! А вот зачем:

• Баги ловятся сразу. Не через две недели, а пока ты ещё помнишь, что там написал. Чувствуешь разницу? Как поймать муху на хуй, пока она не улетела.
• Интегрироваться перестаёт быть пиздецом. Вливать маленькие изменения постоянно — это как пить пиво по глотку. А вливать одну гигантскую порцию раз в релиз — это как выпить ящик водки залпом. Итог предсказуем: тебя просто вырвет на всех.
• Качество кода растёт. Потому что если твой код не проходит линтер или тесты — его просто не пустят дальше. Никаких «ой, да ладно, я потом исправлю». Не исправил — сиди, мудак, и исправляй сейчас.
• Обратная связь — мгновенная. Не надо ждать, пока тимлид посмотрит твой пулл-реквест и напишет через день: «А тут, блядь, ничего не работает». Система тебе сама, своей железной рукой, даст по ебалу через пять минут после пуша.

Из чего же, из чего же сделана наша CI-шка?

1. Система контроля версий. Ну, Git, куда ж без него. GitHub, GitLab — обычное дело.
2. CI-сервер. Это такой злобный надсмотрщик, который всё и запускает. GitHub Actions, GitLab CI, старичок Jenkins — кому что ближе.
3. Пайплайн. Это сценарий, инструкция, что и в каком порядке делать. Написал его один раз — и он работает как часы, ебать его в сраку.

Как это выглядит в жизни? Ну, примерно вот так, простой примерчик:

# Это конфиг для GitHub Actions, файл .github/workflows/ci.yml
name: CI Pipeline
on: [push, pull_request] # Запускается при любом пуше или создании пулл-реквеста

jobs:
  build-and-test:
    runs-on: ubuntu-latest # Крутится на свеженькой убунту
    steps:
      - name: Checkout code
        uses: actions/checkout@v3 # Первым делом — вытягиваем код из репозитория

      - name: Set up Node.js
        uses: actions/setup-node@v3 # Ставим нужную версию Node.js
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm ci # Чистая установка зависимостей, чтоб всё чётко

      - name: Run linter
        run: npm run lint # Запускаем линтер, чтобы код был красивый и не вонял

      - name: Run unit tests
        run: npm test # Гоняем тесты. Упал хоть один — всё, пиздец, пайплайн красный.

      - name: Build project
        run: npm run build # И, наконец, собираем проект. Если сборка упала — всё, пиши пропало.

Вот и вся магия. А CI — это, можно сказать, фундамент. Потому что дальше идёт Continuous Delivery (CD) — это когда твой уже проверенный и собранный код автоматом выкатывается на сервера. Но это уже совсем другая история, с ещё большим количеством автоматизации и возможностей всё разъебать одним коммитом.