Pull to refresh

Comments 7

Вы обещали разобрать вопрос, а вместо этого прошлись по чрезмерно упрощённым верхам. Основная сложность в CI/CD не в настройке пайплайна/workflow (это может написать любая обезъяна, владеющая yaml'ом), а разграничении продакшен/стейджинг. Вся боль - там. Мы хотим воспроизводимый пайплайн при работе с flaky внешним провайдером. У нас приложение с тяжёлыми сайд-эффектами, но мы хотим быстрый пайплайн. У нас секрет для интеграции с платёжной системой, но мы хотим, чтобы стейджинг не мог хулиганить, но при этом хотим проверить, что код работает правильно. У нас приложение обсыпается и мы хотим иметь логи от приложения после завершения пайплайна, но мы не хотим видеть логи от приложения от соседнего пайплайна. Мы хотим получать ответ от CI-сервера за 15 минут, но полный цикл деплоя занимает 2 часа. Бюджет CI - 10 баксов на прогон (верхняя граница), а ТолстаяБаза жрёт 8 баксов только на запуск. И т.д.

Спасибо за ценный комментарий, мы забрали поднятые проблемы в список потенциальных тем по CI/CD. Для DevOps-инженеров, которые уже настраивают CI/CD в ней действительно нет нового. В этом материале план и был пройтись по основам.

Казалось бы материалов и так есть немало, но идеальных материалов не бывает. Одна статья глубже, другая понятней, в третьей описаны нюансы.

UFO just landed and posted this here

Цена ошибок в коде велика, и часто их причиной становится человеческий фактор.

Часто?! Скажите, а сколько раз за свою жизнь вы встречали ошибки в коде по другим причинам? Ну, не знаю, например, из-за сбоя железа или стихийных бедствий?

Пример простой - неверные требования.

Если программа решает задачу, но не ту, то ошибка скорее всего не в коде. И CI или CD тут не всегда поможет. Да и опять же, не боги ведь требования пишут.

На КПДВ показана гидроэлектростанция на Вальхензе в Альпах, вода, естественно, течёт сверху вниз. Получается последовательность Deploy->Test->Build. Странно это как-то.
Sign up to leave a comment.