После нескольких недавних обсуждений, как внутренних, так и по вопросам заказчиков, хочу написать буквально два слова об управлении релизами. Первое – когда пакетирование изменений в релизы имеет смысл, второе – как часто выпускать релизы.
Вопрос о том, когда применять практику управления релизами – не праздный, поскольку эта практика несет с собой не только плюсы, но и минусы, замедляя среднюю скорость внедрения готовых к развертыванию изменений в продуктив. С моей точки зрения пакетирование изменений в релизы «показано» по отношению к тем системам, которые удовлетворяют следующим двум требованиям:
- система является критичной / значимой для заказчика – её простой или нарушения в работе в течение нескольких часов крайне нежелательны (критичность, например, может выражаться в заметных потерях от простоя, или в нарушении работы очень большого количества пользователей);
- по данной системе поступает довольно плотный поток запросов на средние и небольшие доработки, для ориентира скажем 25+ запросов в месяц.
Именно в этом случае польза от релизов, выраженная в виде сокращения количества плановых или непредвиденных остановок системы и более предсказуемого расписания внедрения, может перевесить негатив от снижения средней скорости внедрения. Хотя эту идею еще может быть придется «продавать».
Что касается частоты выпуска релизов, то здесь картина довольно проста – при прочих равных условиях и разработчик, и заказчик заинтересованы в частых релизах. Для заказчика частые релизы – это сокращение времени внедрения, а для разработчика – повышение вероятности обнаружить ошибку при тестировании и быстрее локализовать её в продуктиве, если в ходе тестирования её обнаружить не удалось. Меньше кода – меньше ошибок, что подметил еще тов. Эйнштейн в начале 20-го века (см. картинку).
Что снизу ограничивает интервал выпуска релизов? В первую очередь – стоимость. Чаще релизы – выше затраты на инфраструктуру для тестовых сред, больше трудозатраты на их подготовку, организацию тестирования (иногда не только функционального, но и регрессионного, и нагрузочного), выполнение развертывания (особенно в распределенных системах крупных предприятий). Поэтому для крупных компаний «частые» релизы – это раз в месяц (не очень частые – квартал), для небольших – раз в несколько дней (не очень частые – 2+ недели).
Вот такие простые соображения. Годятся?
Про ограничения снизу. В свете моднодного нынче подхода "шустро"(Agile) появился ряд инструментов, позволяющих в значительной степени нивелироватьэти ограничения. Первый класс инструментов – виртуализация сервиса, когда для тестирования используется не сама система, а запись её поведения, своего рода эмулятор. Кстати, самой системы может даже еще и не быть, а есть только согласованная модель поведения. Это, во-первых, значительно снижает стоимость тестовой среды(вместо мэйнфрейма используется малюсенькая виртуалка, которая "внешне" выглядит как майнфрейм ) и во-вторых, что не менее важно, позволяет максимально приблизить тестирование к разработке. Разработчик может сам оперативно протестировать свой код. Второй каласс ситем – ситемы автоматизации выполнения релиза. Ну тут все понятно.
В пределе обещается что выпуск релизов превратится в непрерывный процесс.:)))