Управление выпуском ПО редко попадает в стратегические планы или отчеты о результатах деятельности ИТ-отдела. Тем не менее, когда это делается хорошо, это облегчает жизнь, пишет на портале InformationWeek Мэри Шеклет, президент консалтинговой компании Transworld Data.
Исторически сложившийся подход к выпуску новых версий ПО заключается в том, что все усовершенствования объединяются в один новый релиз, который затем пакетом распространяется среди пользователей. Однако сегодня все большее число поставщиков облачного ПО и внутренних ИТ-групп, работающих по методологии Agile, выпускают новые обновления ПО на непрерывной основе, причем делают это по мере появления изменений.
У каждого метода есть свои плюсы и минусы, и ИТ-специалистам необходимо по-разному подходить к этим двум стилям распространения улучшений.
Вот несколько лучших практик для выпуска ПО, включая пакетные и непрерывные выпуски:
1. Поставьте цель достичь совершенства (общая практика)
В глубине души все мы, ИТ-специалисты, хотим, чтобы установка нового ПО прошла успешно. Однако за все то время, что я работаю в ИТ, включая годы руководства, я ни разу не видела, чтобы ИТ-отдел сформулировал набор желаемых целей для установки нового ПО.
Эти цели должны заключаться в том, чтобы установить новый релиз без проблем, без сбоев в работе конечных бизнес- или ИТ-систем. Новый выпуск ПО должен сразу же стать продуктивным и принести пользу пользователям. Это ПО должно всегда работать хорошо, а ИТ-специалисты и конечные пользователи должны быть уже знакомы с новыми возможностями, которые содержит данный выпуск.
2. Всегда сначала читайте примечания к выпуску (пакетная практика)
Документация по релизам, предоставляемая поставщиками ПО, обычно многословна и плохо написана. Неудивительно, что ИТ-специалисты и конечные пользователи склонны вообще не читать примечания к выпуску.
Обычно это происходит так: примечания прочитываются бегло, в надежде, что основные проблемы или изменения выявлены и спланированы. Более эффективный, хотя и более громоздкий подход — внимательно изучить примечания, убедившись, что конечные пользователи вместе с новым выпуском также получили относящуюся к ним соответствующую документацию. Если возникнут вопросы, обратитесь к поставщику за разъяснениями.
Таким образом, ИТ-отдел может получить лучшее понимание того, что содержит новый релиз и как он может повлиять на другие системы. Конечные пользователи получают предварительный обзор новых возможностей ПО, чтобы они могли планировать их внедрение в свои бизнес-процессы.
3. Если релиз включает ряд усовершенствований, сначала следует провести их регрессионное тестирование (пакетная практика)
Новый релиз ПО для крупной базы данных или ERP-системы включает в себя множество усовершенствований, которые затрагивают множество различных областей ваших систем и приложений. Новые выпуски основных ОС могут иметь такой же эффект.
По этой причине подход «снести и заменить», при котором просто устанавливается новый релиз без предварительной проверки производительности и интеграции с окружающими системами в тестовом режиме, может стать рецептом катастрофы.
Лучший подход к релизу крупного ПО — это сначала опробовать его в тестовой среде, которая эмулирует вашу производственную среду. Это позволит вам проверить его влияние на скорость обработки и транзакций, обнаружить «поломки» в интеграции, возникающие из-за введения нового кода, и другие проблемы.
Пока новый релиз крупной части ПО не будет тщательно и успешно проверен в тестовой среде, эмулирующей производственную, не запускайте его в производство.
4. Имейте план «отступления» (непрерывная практика)
Цель и преимущество постоянного выпуска новых улучшений по мере их готовности заключаются в том, что пользователи сразу же получают от них пользу. Таким образом, им не нужно ждать несколько недель или даже месяцев, пока большой пакетный релиз будет готов к распространению. Недостатком выпуска новых улучшений по частям, как только они становятся доступными, является то, что системная интеграция может быть недостаточно хорошо протестирована. Это может привести к перебоям в обслуживании.
Одна из стратегий, позволяющих справиться с установкой разовых улучшений, заключается в наличии плана «отступления». Другими словами, если новое усовершенствование неожиданно и негативно повлияет на другие системы и функции, его можно будет немедленно отменить, а системы восстановить в том виде, в котором они были до установки. Для этого необходимо выполнить несколько шагов. Во-первых, устанавливаемое программное улучшение должно быть структурировано таким образом, чтобы его было легко устанавливать и удалять. Во-вторых, пользователи должны быть проинформированы о стратегии отката и о том, как и когда она будет использоваться. То есть все должны понимать и быть согласны с подходом с возможным откатом.
5. Будьте в контакте с поставщиком ПО (непрерывная практика)
Прежде чем подписать контракт с поставщиком, который использует стратегию непрерывного выпуска ПО, опросите его клиентов об успехах (или их отсутствии) установки отдельных усовершенствований ПО. Работали ли эти усовершенствования без сбоев? Смогли ли пользователи сразу же использовать новые функции? Как поставщик уведомляет клиентов о новых и предстоящих усовершенствованиях?
Даже при непрерывном развертывании ПО полезно, чтобы и ИТ-специалисты, и пользователи получали «предупреждения» до того, как усовершенствования вступят в силу.
Если вендор имеет репутацию поставщика плохо разработанных или плохо информируемых усовершенствований для непрерывных релизов, но вы все равно хотите использовать его, вы можете заключить соглашение, которое даст вам возможность выбирать, какие усовершенствования и когда вы хотите внедрять.
6. Будьте «гибким» с Agile (непрерывная практика)
Что замечательно в методологиях разработки приложений Agile и DevOps, так это то, что пользователи и ИТ-специалисты работают вместе и могут договориться, когда новое приложение должно быть запущено. Бывают случаи, когда пользователи вполне довольны «несовершенным» приложением и начинают его использовать, как только получают достаточную функциональность.
Все в порядке, если пользователи и ИТ-специалисты согласны использовать несовершенное приложение, особенно если речь идет только о внешнем графическом интерфейсе пользователя (GUI). Однако, как только вы переходите к бэкенд-интеграции GUI или приложения с другими системами, эта интеграция должна быть протестирована, и ее не следует устанавливать в производство, пока она не будет работать идеально.
