Continuous Delivery бессмысленен?

Недавно я написал в Твиттере о непрерывной доставке:

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

Это честно. Непрерывная доставка — крайний случай. Давайте обсудим эти случаи.

Во-первых, нам нужно убедиться, что мы одинаково понимаем наше определение Continuous Delivery. Непрерывная поставка — это рабочий процесс, в котором небольшие изменения вносятся очень часто и интегрируются в магистраль управления версиями. Оттуда артефакт либо сертифицируется конвейером как соответствующий нашему определению «релизного», либо артефакт отклоняется, и мы немедленно исправляем причину, по которой он был отклонен. Мы всегда находимся в состоянии, когда мы можем выпустить последние изменения в продакшен. Чем чаще мы это делаем, чем меньше изменения, тем меньше риск возникновения серьезных дефектов и тем быстрее мы можем получить обратную связь о ценности изменения. Зачем нам это делать? Это нормально для простого веб-сайта, но зачем делать это для «настоящих» приложений?

Безопасность

Одним из крайних случаев является безопасность. Только если мы рассматриваем безопасность как проблему, мы должны беспокоиться об этом. Почти каждое приложение имеет уязвимости в системе безопасности. Вопрос только в том, известны они или нет. Когда о них становится известно, они представляют собой риск, который необходимо быстро снизить. Во-первых, нам нужно убедиться, что мы проверяем проблемы безопасности при каждом изменении, а не ежегодно. Нам нужны шлюзы качества безопасности в нашем конвейере, и нам нужно регулярно проверять этот конвейер, чтобы выявлять новые уязвимости в наших системах по мере их поступления. Когда они обнаружены, нам нужно немедленно их исправить. Чтобы сделать это быстро, нам нужен стандартный способ убедиться, что мы не нарушили существующее поведение при применении исправления безопасности. Нам нужна уверенность, чтобы сделать исправление, отправить его в релиз и через несколько минут узнать, что мы можем его выпустить. Хорошим примером является уязвимость Log4J. Высокоэффективные организации, которые внедрили стандартизированные автоматизированные приемочные тесты, исправили ее в течение одного рабочего дня.

Соответствие правилам

Еще один пограничный случай — жестко регулируемая среда. Нам необходимо убедиться, что мы придерживаемся всех стандартов, которые будут проверять Аудиторы. Нам нужно делать это при каждом изменении кода, и нам нужно блокировать несоответствующие изменения. Одно общее требование состоит в том, чтобы за каждым изменением следили две пары глаз, чтобы предотвратить недобросовестных игроков. Мы должны иметь встроенные в наши пайплайны контрольные точки, чтобы обеспечивать это, а не обнаруживать у нас проблемы во время аудита и потом иметь юридические последствия.

Высокая доступность

Другим «редким» случаем является необходимость круглосуточной доступности систем. Когда возникают проблемы с этими системами, нам нужен стандартный подход к их ремонту в 3 часа ночи в полусне, чтобы снизить риск усугубления плохой ситуации. В тех редких случаях, когда мы работаем с подобными системами, нам необходимо усовершенствовать наш стандартный метод доставки исправлений, используя его как единственный способ развертывания улучшений в системе. Таким образом, мы можем использовать мышечную память и проверенные ворота качества для внесения исправлений и снижения воздействия ошибок.

Качество

Еще один пограничный случай — когда мы работаем над системами, где важно качество. Удивительно, но некоторые программы требуют уровня качества, выходящего за рамки разработки класса «подержи мое пиво!». Качество — это процесс, который требует быстрой обратной связи по вопросам качества и способности своевременно их решать. Наличие полностью автоматизированных и быстрых контрольных точек качества и возможность доносить небольшие изменения конечному пользователю для получения дополнительной качественной обратной связи очень важны для таких систем. Только в системах, где качество не имеет значения, мы должны использовать искусственные методы ручного тестирования и ежемесячные или ежеквартальные поставки.

Итак, обширны такие крайние случаи для CD?

Если вы думаете, что это бессмысленно, вы, вероятно, не продумали все проблемы. Можно не соглашаться, но приведите реальные доказательства, чтобы мы могли обсудить это. Я буду рад узнать что-то новое.

Если вам нужна помощь в начале пути, мы пытаемся упростить ее на сайте MinimumCD.org.

Источник