Наши службы должны где-то работать, чтобы наши пользователи могли получить к ним доступ. Очень распространена практика иметь несколько сред, таких как dev, staging и prod. Действительно ли это хорошая практика?
CI vs. CD vs. CD
когда люди говорят о непрерывной интеграции, доставке и развертывании, они обычно говорят об этом в целом.
Тем не менее, давайте задумаемся, почему это 3 разные практики. Поскольку это шаги в путешествии, вы можете сделать один, а не следующий.
- Непрерывная интеграция: позволяет создавать воспроизводимые состояния кода в нескольких местах.
- Непрерывная доставка: теперь, когда она воспроизводима, ее необходимо пометить как потенциально развертываемую и предоставить возможность ее развертывания.
- Непрерывное развертывание: доставляет код вашим клиентам, а не только вашей команде, по мере того, как вы делаете коммит.
Ловушка множественных окружений
Как вы понимаете, при предыдущем определении CI/CD наличие нескольких сред никогда не позволит вам добиться непрерывного развертывания.
Цель наличия нескольких сред — снизить частоту неудачных изменений. Действительно ли мы достигаем этого с помощью практик? Ответ обычно не связан с:
- Непроизводственная среда никогда не будет такой же, как производственная.
- Разные данные
- Различная производительность
- Различные методы обеспечения безопасности
- И т. д…
- Стресс и право собственности на перемещение вещей в производство
- Накопление кода в более низких средах (что означает больше ошибок).
- Более длинный цикл обратной связи.
- Постоянное несовпадение из-за циклов разработки между разными командами.
Как видите, это создает ложное чувство безопасности, но не влияет положительно на частоту неудачных изменений.
Это в основном негативно сказывается на большинстве метрик ДОРА 4:
- ❌ Частота развертывания
- ❌ Время подготовки к изменению
- ❌ Среднее время восстановления
- 〰️ Изменить показатель отказов
Достижение непрерывного развертывания, только прод, это так безумно?
Как команда может использовать непрерывное развертывание? Ответ, как правило, прост: каждый коммит отправляется в производство и тестируется в нем.
Имейте в виду, что это не означает, что наши пользователи сталкиваются с возможными ошибками или видят тестовые данные, поскольку мы можем скрыть функциональные возможности за ними. переключатели, заголовки или параметры, которые разрешают доступ только команде разработчиков. Как мы увидим в следующих частях этой серии.
Пример стратегии показан на следующей диаграмме.
Это позволяет нам сохранить только одну среду, которая различает тестовые и нетестовые данные, которые можно периодически очищать, в то время как реальная среда обеспечивает реальное поведение. При этом мы решили:
- Реальная производительность и поведение.
- Постоянное согласование с другими командами.
- Меньшие циклы обратной связи.
- Контроль выкатывания.
- Меньшая стоимость $.
Это влияет на следующие показатели DORA 4:
- ✔️ Частота развертывания
- ✔️ Время подготовки к изменению
- ✔️ Среднее время восстановления
- 〰️ Изменить показатель отказов
Заключение
Не существует универсального решения для всех, но современные практики стремятся к простоте и быстрой обратной связи. Есть много практик, связанных с этой простотой, которая позволяет нам чувствовать себя комфортно только с производственной средой. О них мы и поговорим в этой серии.
