Обложка канала

.NET Разработчик

Опытный разработчик не так давно зашёл в .Net и поставил цель получить сертификат Microsoft. Свой ежедневный прогресс он описывает на канале .Net Разработчик. Заметки об изученном материале, советы по повышению производительности и поддержке мотивации, ин

.NET Разработчик

4 года назад
Открыть в
День 1137. Развёртывайте Чаще Если вы ещё не практикуете непрерывное развёртывание, скорее всего, ваша команда и компания выиграют от более частых развёртываний. Развёртывание (deploy) ПО — это процесс переноса его из среды разработки в производственную (или другую) среду. Развёртывание не то же самое, что выпуск (release). В идеале вы должны иметь возможность часто развёртывать ПО, выпуская новые функции для клиентов только тогда, когда это целесообразно с точки зрения бизнеса. Считаете ли вы развёртывание стрессовым, болезненным и требующим от членов команды внеурочной работы? Что, если бы вы могли избавиться от этого, развёртывая ПО в любое время, но выпуская его только тогда, когда это удобно для вашей команды и/или пользователей? Ключевым средством разделения развёртывания и выпуска являются флаги (переключатели) функций. Вы можете развернуть код, который ещё не готов, и «скрыть» его за флагом. Как только функция будет готова, и бизнес определит, что пришло время выпустить её, флаг можно переключить, и функция станет активной. И даже этот процесс можно запланировать. Клиенты, с которыми я работал, развёртывали ПО нерегулярно, примерно раз в 6-8 недель по решению руководства. Поскольку их клиенты приходили в офис к 8 утра, команда должна была начать развёртывание в 3 часа ночи. Процесс почти никогда не проходил по плану: хотя первоначальное развёртывание занимало всего 10-15 минут, остальное время уходило на тестирование, исправление ошибок и повторное развёртывание, чтобы система заработала к 8 утра. А иногда приходилось откатываться и планировать развёртывание на другой день. Если вы развёртываете редко, вы почти наверняка внедряете изменения, которые были завершены несколько недель или месяцев назад. Если что-то пойдёт не так с этим кодом, разработчик, который его написал, вероятно, уже забыл о нём к этому моменту, а то и вовсе уволился. При более частом развёртывании все вносимые изменения остаются свежими в памяти команды, поэтому выявление и устранение любых проблем становится намного проще. Для моих клиентов сначала мы собрали метрики о периодичности развёртываний и их успешности. Успешным считалось развёртывание, которое не пришлось откатывать или немедленно исправлять ошибки в нём. Оказалось, что развёртывания, которые выполнялись спустя неделю после предыдущего, почти никогда не были успешными. Тогда как те, что выполнялись спустя день, в большинстве случаев не требовали исправлений. «Если больно, делай это чаще». Мы решили выполнять развёртывание чаще. Команде предложение не понравилось. Дни развертывания никому не нравились. Это были дни сильного стресса, бессонницы, которые мешали работе и личной жизни людей. А их просили делать это чаще. Однако, мы выяснили, что развёртывания после длинного перерыва были высоким стрессом и полной неопределенностью, тогда как те, что выполнялись сразу после, проходили гораздо легче. Это понятно, ведь изменений было немного. Так почему бы не продолжать в том же духе? Команда решила проводить развёртывания по вторникам и четвергам. Они планировали выполнить 50 развёртываний в год вместо 10, как было раньше. Однако им удалось сделать 100 и более 90% из них были успешными. Больше никому не приходилось выполнять стрессовое развёртывание в 3 часа ночи. Итого Процесс доставки ПО является важной частью успеха вашей команды (и компании). Существует множество причин, по которым вы должны предоставлять функционал клиентам раньше и чаще. Проблемы, которые непропорционально возрастают с размером развёртывания, можно контролировать. Стоимость тестирования и исправления ошибок растёт со временем не линейно, а экспоненциально, поэтому, чаще развёртывая, вы сокращаете время, в течение которого могут возникнуть большие проблемы. А с мелкими, которые успевают возникнуть, справиться гораздо легче. Источник: https://ardalis.com/deploy-more-often/ Автор оригинала: Steve “Ardalis” Smith