Что стоит включать в CI пайплайн

Ага, слушай, вот это тема! Ты про эти ваши пайплайны, которые как конвейер на заводе, только для кода? Ну, чтобы не вышло как в том анекдоте: "собрали, запустили — а там пиздец, всё горит синим пламенем". Так вот, чтобы этого не было, умные дядьки придумали вот эту хуйню — CI/CD.

Представь, ты написал код. И вместо того, чтобы вручную, как последний лох, бегать и проверять "а линтер не ругнётся? а тесты пройдут? а соберётся ли во что вменяемое?", ты просто пихаешь это всё в репозиторий. А дальше в дело вступает эта самая пайплайна, как злая, но справедливая тёща. Она всё проверит, всё обнюхает и если где-то накосячил — сразу по лбу настучит, ещё до того, как твой кривой код попадёт к другим людям или, не дай бог, на продакшен.

Вот смотри, из чего обычно эта тёща состоит, по пунктам:

1. Линтинг кода (ESLint, Stylelint). Это как проверка орфографии и пунктуации, только для программистов. Чтоб запятые стояли где надо, отступы были красивые, и ты не использовал устаревшие или тупые конструкции. npm run lint — и если ты мудак и написал хуйню, она тебе красным подсветит. "Идиот, тут же точка с запятой нужна, ёпта!"

2. Тестирование. А вот это уже серьёзнее. Это проверка, а не сломал ли ты случайно то, что работало вчера. Юнит-тесты — как проверка каждого винтика по отдельности. Интеграционные — а сойдутся ли эти винтики вместе. E2E — а поедет ли вся эта собранная тачка из пункта А в пункт Б. Запускаешь npm test и молишься, чтобы всё было зелёное. Если красное — всё, пизда, сиди чини.

3. Сборка проекта. Ну, тут всё просто. Дал команду npm run build и смотришь — получится ли из твоих сотен файлов один красивый, оптимизированный кусок, который браузер сможет сожрать. Если процесс упал с ошибкой — значит, где-то в коде такой косяк, что даже собрать нельзя. Позор на твою голову!

4. Проверка зависимостей. Это, блядь, очень важно! Ты же качаешь кучу библиотек со стороны (npm-пакеты, ну ты понял). А вдруг в одной из них дыра безопасности, через которую к тебе на сервер хакеры залезут? Запускается npm audit, и если найдётся какая-нибудь уязвимость — сразу крик: "Чувак, у тебя тут left-pad версии 0.0.1, который всю твою базу сливает в интернет! Срочно обновляй, ёбта!"

5. Деплой на staging. Ну, если всё предыдущее прошло как по маслу — можно уже и показать результат, но не всем, а только на тестовый сервер (staging). Там уже можно потыкать, посмотреть, как оно в почти боевых условиях. Автоматом, само выкатится. Красота!

6. Артефакты сборки. А это чтобы то, что успешно собралось, не потерять. Сохранили билд (эти js и css файлы, сжатые-пережатые) — и потом их можно взять и на прод залить, не собирая всё заново.

И вот весь этот цирк с конями обычно описывается в одном файлике, который CI-система (типа GitHub Actions) читает и выполняет. Смотри, как это примерно выглядит, только не пугайся:

name: CI Pipeline
on: [push]
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - run: npm ci
      - run: npm run lint
  test:
    needs: lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - run: npm ci
      - run: npm test
  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - run: npm ci
      - run: npm run build

Видишь? Всё по полочкам. Сначала линтинг (lint). Если он прошёл — запускаются тесты (test). А уж если и тесты не сломались — тогда сборка (build). И каждый следующий шаг зависит (needs) от успеха предыдущего. Упало что-то на первом этапе — дальше даже не начнётся, экономит время и нервы.

Вот и вся магия. Кажется, овердохуища работы, но зато потом спишь спокойно. Ну, почти спокойно.