x
 
Фёдор Борщёв
30 июля 2020
Советы почтой каждую неделю
Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:

Непрерывная доставка


Непре­рыв­ная доставка (англ. Continuos Delivery) — это прак­тика, при кото­рой содер­жи­мое мастер‑ветки репо­зи­то­рия все­гда нахо­дится на про­дак­шене: сде­лал ком­мит — сер­вер авто­ма­ти­че­ски обно­вился, и так несколько раз в день. Обычно доставка — это финаль­ная часть про­цесса непре­рыв­ной интеграции.

В клас­си­че­ском релиз­ном цикле при­нято копить изме­не­ния в боль­шие пачки и выкла­ды­вать их все вме­сте. Ска­жем, если вы в один день сде­лали две фичи, одна из кото­рых изме­няет струк­туру дан­ных, а дру­гая добав­ляет полез­ную функ­ци­о­наль­ность для поль­зо­ва­те­лей, то в про­дак­шен они «поедут» вме­сте. Если мигра­ция из пер­вой фичи почему‑то не прой­дёт, то вто­рая фича с полез­ной функ­ци­о­наль­но­стью тоже, ско­рее всего, не запустится.

Или вы неделю делали боль­шую фичу, для работы кото­рой нужно обно­вить вер­сию фрейм­ворка, сде­лать пять раз­ных мигра­ций и запу­стить 2000 строк кода. В клас­си­че­ском релиз­ном цикле вы, ско­рее всего, будете запус­кать её разом, и если хотя бы в какой‑то из этих частей что‑то пой­дёт не так — вы узна­ете об этом в самый послед­ний момент, близко к дедлайну.

При непре­рыв­ной доставке всё проще: напи­сали код — и сразу выкла­ды­ва­ете на про­дак­шен. Можно даже выкла­ды­вать частями — ска­жем, нашу гигант­скую фичу на 2000 строк можно выло­жить четырьмя малень­кими кусоч­ками по 500 строк. Полу­чится, что к моменту запуска уже бо́льшая часть вашего кода будет на про­дак­шене, а зна­чит, все вещи, кото­рые могли выстре­лить в момент пуб­ли­ка­ции, напри­мер непро­хо­дя­щие мигра­ции, ско­рее всего, выстре­лят заранее.

Рабо­та­ю­щая непре­рыв­ная доставка — при­знак высо­кой инже­нер­ной куль­туры. К при­меру, в клас­си­че­ском под­ходе каж­дый релиз — это боль­шая работа для тести­ров­щика: нужно руками про­ве­рить, что ничего не сло­ма­лось. Если достав­лять код несколько раз в день, при­дётся либо нани­мать нера­зум­ное коли­че­ство тести­ров­щи­ков, либо всё‑таки авто­ма­ти­зи­ро­вать тести­ро­ва­ние. Выкла­ды­ва­ние кода тоже при­дётся авто­ма­ти­зи­ро­вать — если вы при­выкли вруч­ную пере­кла­ды­вать файлы и запус­кать ком­пи­ля­цию ассе­тов, то ника­кой непре­рыв­ной доставки у вас не получится.

См. также:

P. S. Это был совет об управлении разработкой. Хотите больше знать о планировании спринтов, управлении продуктом или о настройке инфраструктуры? Присылайте вопросы.

Поделиться
Отправить

Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

Как написать аккуратный код? Часть четвёртая: ответственность Как и когда зарождающийся стартап в процессе своего развития должен подходить к вопросу имплементации билинга? Новичок в команде считает, что стандарты качества продуктов низкие, а знания и опыт устарели из-за инертности 3 Как быть разработчикам, которые хотят получать больше денег, но не хотят разбираться в бизнесе?




Недавно всплыло

Практика: формулировка полезного действия 9 Мне пока ни разу не удалось выбрать человека, который написал бы правильный текст 1 Некоторые редакторы переписывают твои советы, а потом продают как свои курсы 2 3