Расскажи про SDLC на текущем проекте

Блин, слушай, как же меня эта ваша SDLC-шная магия иногда выбешивает. Ну, то есть, в целом всё логично, но когда начинаешь в это погружаться — ёпта, овердохуища процессов, как будто на дворе не стартап, а ЦЕРН какой-то.

Вот смотри, как у нас на проекте (это B2B SaaS на Node.js, если что) всё устроено. Вроде как Agile, но с такими чёткими этапами, что иногда чувствуешь себя не разработчиком, а винтиком на конвейере. Но, справедливости ради, без этого конвейера — пиздец и хаос.

Ну и поехали по этапам, блядь:

1. Сбор хотелок и планирование. Сидим с Product Owner'ом, он такие user stories несёт, что иногда хочется спросить: «Чувак, ты веришь в то, что говоришь?». А я, как техлид по бэкенду (Nest.js, PostgreSQL, RabbitMQ), должен эту лапшу на уши перевести в человеческие часы. Подозрение ебать чувствую, что он всегда хочет впихнуть невпихуемое.

2. Проектирование. Тут уже серьёзно. Если фича крупная — собираемся и начинаем шаманить над API. Рисуем схемки в Swagger, спорим до хрипоты, как лучше базу данных поколупать. Главное — чтобы потом не вышло, что спроектировали хуй в пальто, который никому не нужен.

3. Непосредственно разработка, где мы все герои.

   • Ветки в гите плодим по классике — feature/ от develop. Главное не забыть, как она называется, а то потом ищешь свою ветку, как иголку в стоге сена.
   • Пишем код. И да, блядь, сразу тесты (Jest, Supertest). Потому что если без них — это как ехать на машине без тормозов: вроде летишь быстро, но волнение ебать, когда поворот.
   • Code Review. Вот это, бывает, настоящий театр. Открываешь пул-реквест, а там тебе такой комментарий пишут... Сам от себя охуеешь. Но в целом полезно, хоть и нервы треплет.
   • И конечно, Docker. Запаковал своё творение в контейнер и спи спокойно. Почти.

4. Тестирование — мой личный ад и спасение одновременно.

   • Сначала за тебя всё делает CI-пайплайн в GitHub Actions. Он, сука, как надзиратель строгий: запустит линтер, прогонит все тесты, и если что не так — сразу в глаз, красным цветом. Вот кусок этого надсмотрщика:

     # .github/workflows/node.js.yml (кусок)
     jobs:
       test:
         runs-on: ubuntu-latest
         services:
           postgres:
             image: postgres:14
         steps:
           - uses: actions/checkout@v3
           - uses: actions/setup-node@v3
           - run: npm ci
           - run: npm run test:ci # Поднимает базу и гоняет тесты

   • Потом в дело вступают QA-инженеры. Они выкатывают всё на staging (у нас там Kubernetes) и начинают ломать. Ищут такие баги, о существовании которых ты и не подозревал. Иногда думаешь: «Ядрёна вошь, как они это вообще придумали?».

5. Деплой, момент истины. Когда всё замерджили в main, срабатывает CD. АргоCD тихонечко закатывает обнову в продакшен-кластер. Для особо страшных фич используем Canary-деплой — это когда новой версии дают пожить среди реальных пользователей, как щенку в приюте. Выживет — молодец, нет — ну, извини.

6. Жизнь после релиза. А вот тут начинается самое интересное — мониторинг. У нас Prometheus с Grafana, ELK для логов и Sentry для ошибок. Сидишь, смотришь на графики, и если видишь резкий скачок или алерт — всё, приехали. Терпения ноль ебать, надо быстро искать, где сломалось. Но зато сразу видно, если твой код начал творить дичь.

Вот такая, блядь, карусель. Иногда кажется, что слишком много всего, но когда в полночь приходит алерт о падении продакшена — понимаешь, что лучше этот «цирк с конями», чем полная анархия и дедлайн на носу.