Подготовка к выкладке практически бесполезна, пока мы не решим, как именно будем проводить деплоймент. В зависимости от масштабов вашего проекта, количества компонент, требований к скорости и синхронности обновления, можно выбрать наиболее подходящий способ выкладки. Перечислю, в порядке нарастания сложности, основные.
Подробнее
Выкладка релизов (часть вторая) – способы деплоймента
Пакеты задач в системе контроля версий
Использовать пакеты для объединения входящих задач в единую предназначенную для управления сущность – удобно. Но если бы вся выгода от внедрения пакетов заключалась только в их организационной составляющей, сомневаюсь, могла бы я с такой уверенностью советовать их кому бы то ни было.
Достоинство пакетов в том, что они легко и непринуждённо превращаются в знакомые всем ветви системы контроля версий.
Подробнее
Не релизом единым жив человек
В каком релизе и когда выйдет этот функционал? Сколько времени нужно на тестирование релиза и когда оно закончится? Сколько релизов выйдет за квартал? Такие привычные вопросы, такие естественные – и такие временами раздражающие.
Мне понадобилось несколько месяцев работы на конвейере, чтобы понять, что именно не устраивает в использовании релиза как консолидированной сущности для разработки, тестирования и выкладки функционала:
- Релиз появляется тогда, когда принято решение о необходимости выкладки того или иного набора задач на боевые сервера. Обновление боевой среды – процесс строго последовательный, и выложить седьмой релиз до пятого нельзя. Сохранение жёстко заданной последовательности не кажется проблемой при малом количестве релизов, медленной разработке и аккуратном планировании на несколько месяцев вперёд. Но как быть, если завтра к вам придут с задачей, которая должна появится на боевых уже послезавтра? Изменять заранее декларированную последовательность релизов? Нарушать нумерацию? Выпускать хотфиксы, являющиеся, по сути, мелкими релизами? Да, иногда можно и так – но нельзя ли лучше?
- Релиз многими воспринимается как нечто неделимое и неизменяемое. Не успели добавить заказ в девятый релиз? Увы, вам придётся подождать десятого. Нашли при тестировании баг? Выпускаем новый билд и тестируем его заново. О, как это негибко! И совершенно неприемлемо в условиях постоянной смены приоритетов и требований. Если я хочу уверенно жонглировать входящими задачами, выкидывая наверх то самую нужную сейчас, то наиболее готовую, то наименее опасную, я не могу позволить себе ни длительного планирования, ни отказов заказчику на том только основании, что текущий большой релиз уже давно в тестировании.
Решение нашлось простое: оставить за релизом только одну функцию – деплоймент, а разработку и тесно связанное с ней тестирование передать новой сущности – «пакету задач». При этом релизы остаются строго последовательными, а пакеты распараллеливаются на произвольное количество потоков.
Подробнее