Настоящий CTO: думай как технический директор - Алан Уильямсон

При проведении релиза необходимо информировать всех заинтересованных лиц о выполнении каждого этапа. Не скрывайте плохие новости – если все затянется или пойдет не по плану, лучше сказать об этом, чем устраивать радиомолчание и заставлять людей думать, что процессом никто не управляет.

В идеале, особенно если вы делаете релизы часто, найдите время для тестовых прогонов. Это не всегда возможно, в зависимости от того, какая система требует обновления. Например, миграция бэк-офисной системы (такой как электронная почта) с одной платформы на другую занимает много времени, и проверить ее в полном объеме может быть сложно.

После завершения релиза проведите ретроспективу, чтобы отметить, что прошло хорошо, и изучить, что пошло не так или что можно сделать лучше в следующий раз.

9.7.2. Сине-зеленое (blue-green) внедрение

Традиционно, когда кто-то думает об обновлении, он представляет себе замену кода на сервере (то есть буквальную замену файлов в файловой системе). Это сопряжено с большим риском и, конечно же, усложняет откат к предыдущему состоянию, потому что в файловую систему были внесены изменения.

Появление виртуализации, благодаря которой запуск новых серверов стал занимать минуты или даже секунды, открыло возможности для радикального переосмысления многих подходов к работе, и, в частности, к выпуску релизов. Вместо обновления текущих серверов вы можете создать совершенно новую копию с новой версией ПО, полностью настроенную и готовую к работе. После развертывания (если вы используете Docker или что-то подобное, можно создать скрипты для его ускорения) вы можете проверить работу новой версии, а «текущий» набор серверов пока продолжит обслуживать запросы от пользователей.

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

Такой способ развертывания называется сине-зеленым (blue-green), и если вы его освоите, то сможете проводить релизы спокойно и безболезненно. Дополнительным преимуществом этого способа является постоянная проверка скриптов для развертывания инфраструктуры. Чем сложнее ваша архитектура, тем сложнее в реализации будет этот способ деплоя, однако ничего невозможного тут нет. И он идеально подходит для веб-приложений.

Одна из самых сложных вещей в любом релизе – изменение схемы базы данных. Правило здесь простое: только добавляйте, никогда не удаляйте. Удаление делает невозможным откатить обновления, не прибегнув к восстановлению из резервных копий. Вы сможете удалить таблицы, столбцы и индексы позже в будущих релизах, когда будете уверены, что этот функционал работает нормально и его не придется откатывать.

Когда вы добьетесь того, что релизы будут хорошо отработаны и будут проходить безболезненно, вы избавитесь от стресса и рисков, связанных с обновлениями, и они перестанут быть значительным событием. Независимо от того, какую стратегию вы выберете, всегда создавайте описание релиза (release notes), в котором описывайте все изменения, – это очень полезная привычка. Это может быть просто текстовый файл, документ в вики или же страница в Atlassian Confluence. Некоторые системы управления задачами позволяют привязывать тикеты или спринты к версиям ПО и автоматически создавать описание релизов.

Это очень полезный документ, особенно если конечный пользователь должен понимать, какие обновления были выпущены. В этом случае описание релиза можно изложить языком, понятным для конечного пользователя.

9.8. Запросы от клиентов

При управлении системой крупного и успешного предприятия вы обязательно будете со всех сторон получать запросы на добавление новых функций. Более важные клиенты, скорее всего, будут в приоритете, и именно они, если вы не справитесь, станут вашим худшим кошмаром. Бизнесу необходимо, чтобы его ключевые клиенты были довольны, и, естественно, он будет стремиться удовлетворить их потребности, чтобы оставаться на плаву.

Поэтому, если вы будете выполнять все такие запросы, то можете обнаружить, что согласуете расходы, которые делаются в интересах только одного конкретного клиента, что создает дополнительную нагрузку и в конечном итоге привязывает вашу платформу к этому клиенту. Что же делать современному техническому директору, который не хочет все время говорить «нет»? Отказы с вашей стороны не добавят бизнесу (или клиентам) любви к вам. Лучше рассматривайте каждый запрос на новый функционал в контексте всех ваших клиентов. Учитывайте следующее:

• Будет ли новая функция представлять ценность для других клиентов? Если да, то она в любом случае должна быть в вашем плане.

• Можно ли дополнительно проработать или обсудить эту функцию, чтобы она стала полезной для более широкого круга пользователей?

• Если эта конкретная функция не имеет ценности для остальных клиентов, есть ли другой способ решить проблему клиента?

Например, технология экспорта/импорта данных позволит клиенту создать внешнее решение, также он может использовать ваше API, если оно есть. Если ваша система имеет возможность настройки для отдельных клиентов – добавьте в нее поддержку плагинов, чтобы ее функционал можно было расширять, не затрагивая основные компоненты. Главное – не позволяйте себе оказаться во всем знакомой ситуации:

if (Client == XYZ) {

// делаем что-то для конкретного клиента

}

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

Заметки с полей

Клиент всегда прав

Я встречал множество примеров в стиле «если клиент такой-то – делать то-то» в портфельных компаниях разного возраста и размера, и все это печальные примеры, потому что с каждым таким решением все сложнее свернуть с порочного пути и каждый такой релиз увеличивает сложность продукта. Другая крайность – когда для конкретного клиента создается отдельная копия всего репозитория. Это самая опасная ситуация, которая гарантированно ведет к катастрофе. Вы сами удваиваете свою рабочую нагрузку. Любые обновления или исправления функций необходимо будет вносить и туда, и сюда, и потом тестировать. Если вы поймаете себя на том, что произносите фразу: «Это же только для одного клиента/просьбы», – немедленно бросайте это дело! Потом вы обязательно скажете себе спасибо.

Итоги

• Определить сроки выполнения проекта сложно из-за внешних факторов и непредвиденных событий.

• Если вы разобьете проект на более мелкие части, например с использованием методологии agile, планировать работу станет проще.

• Хорошо регулируемая и структурированная система управления задачами (тикетами) поможет вам и вашей команде четко понимать состояние проекта.

• В растущей команде жизненно важно иметь сильного руководителя проектов, который будет управлять работой на всех этапах.

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

• Система контроля версий – ваш верный союзник в борьбе с постоянными изменениями.

• Подходящая стратегия работы с бранчами позволит вам вести разработку параллельно без необходимости ждать или составлять сложные графики работ.

• Признание технического долга – первый шаг к тому, чтобы начать его уменьшать.

• Существуют разные способы тестирования, как ручного, так и автоматизированного. Это сложная и трудоемкая работа, но лучше иметь хотя бы какие-то тесты, чем вообще никаких.

• Выпуск релизов не обязательно должен быть сложным и рискованным; весь секрет здесь в планировании, отработке на практике и коммуникации.

• При использовании виртуализации и облачных сервисов вы можете значительно уменьшить риски при выпуске релизов, внедрив сине-зеленое развертывание.

• Поощряйте и приветствуйте обратную связь от клиентов и пользователей; однако это не должно приводить к превращению вашей кодовой базы в беспорядочный набор случайных функций.