Знаменца за функционалности: како да испорачувате без изданија со голем прасок

Повеќето тимови сѐ уште испорачуваат исто како и пред една деценија: работата се натрупува на гранка со недели, се спојува и оди во живо одеднаш на денот на изданието. Сите го задржуваат здивот. Ако нешто се скрши, решението е враќање назад, брза поправка или многу долга ноќ. Иронијата е што алатките за избегнување на ова постојат со години и чинат речиси ништо за усвојување. Се викаат знаменца за функционалности, а повеќето тимови што не ги користат не ги избегнуваат од добра причина — едноставно не стигнале до нив.

Проблемот со големиот прасок

Издание што спојува две недели измени има две недели ризик збиени во еден момент. Ако нешто не чини, не знаете кој од четириесет внесови го предизвикал. Дебагирањето под притисок, во продукција, со засегнат што бара рок, е најлошата можна средина за изолирање регресија. Самото спојување е ризикот — а не која било поединечна измена.

Знаменцата за функционалности разделуваат две работи што изданијата со голем прасок ги спојуваат: поставувањето код и објавувањето функционалност. Кодот може да се спои во главната гранка и да се постави во продукција зад знаменце што е исклучено. Ништо видливо за корисникот не се менува. Функционалноста се објавува подоцна, независно, кога некој ќе го вклучи знаменцето — а тоа вклучување може да биде моментално, насочено и повратно.

Што всушност ви носи едно знаменце

Поставувањата престануваат да бидат настани. Кога поставувањето код и изложувањето функционалност се одделни дејства, можете да поставувате по неколку пати дневно без некој да забележи, зашто ништо не се менува за корисниците додека вие не кажете. Само тоа ја убива најголемата вознемиреност околу испораката — лошо поставување со исклучено знаменце не е настан.

Враќањето назад станува прекинувач, а не поништување. Ако функционалност предизвика скок во грешките, не треба да поништувате внес, да преградувате и да поставувате повторно. Го исклучувате знаменцето. Поправката трае секунди, а не цел циклус, и не бара допирање на кодот што сѐ уште безбедно седи во продукција, оневозможен.

Воведувањето станува постепено по природа. Наместо да испорачате до 100% од корисниците одеднаш, можете да изложите знаменце на 1%, да ги следите стапките на грешки и клучните показатели, па да преминете на 10%, потоа на 50%, потоа на сите. Сѐ што ќе тргне наопаку при поголем обем обично се појавува многу пред да стигнете до целосна изложеност — и го фаќате додека радиусот на штета е сѐ уште мал.

Можете да таргетирате кој што гледа. Знаменцата не се само вклучено/исклучено — можат да се ограничат прво на внатрешни корисници, потоа на конкретен сегмент клиенти, потоа на бета-група што се пријавила. Тоа го претвора „испорачај и надевај се“ во „испорачај им на луѓето што најверојатно ќе дадат корисна повратна информација и најмалку веројатно ќе бидат оштетени од груб раб“.

Каде тимовите грешат

Знаменца што никогаш не се отстрануваат. Знаменцето е замислено како привремено скеле околу конкретно воведување, а не како трајна if наредба. Штом функционалноста е целосно воведена и стабилна, знаменцето и старата патека во кодот треба да се избришат во истиот спринт, а не да се натрупуваат. Код со двесте застарени знаменца е потежок за разбирање од код без ниту едно — секое од нив е разграноување во логиката што некој мора да го држи во глава.

Нема јасен одговорен за одлуката за прекинувачот. Ако никој не е изречно одговорен да одлучи кога знаменцето преминува од 10% на 50% на 100%, тоа седи на 10% шест месеци. Воведувањето бара име прикачено на себе, а не само механизам.

Ставање знаменца на работи што не се ризични. Не секоја измена бара знаменце. Промена на текст или поправка во CSS не бара постепено воведување — тоа е само вишок процес без корист. Резервирајте ги знаменцата за измени со вистински радиус на штета: нови текови на податоци, измени во критични патишта како наплата или автентикација, сѐ што допира наплата, или сѐ за што навистина не сте сигурни како корисниците ќе реагираат.

Знаменцата да се третираат како замена за тестирање. Знаменцето ја ограничува изложеноста ако нешто тргне наопаку; не го заменува проверувањето дека нештото воопшто работи. Тимовите што се потпираат на „ќе ставиме знаменце и ќе видиме“ наместо да пишуваат тестови на крајот ја користат продукцијата како тест-средина со дополнителни чекори.

Почнување во мало

Не ви треба платформа од добавувач за да ја добиете основната корист. Една конфигурациска табела или знаменце базирано на околина со неколку логички прекинувачи ги покрива повеќето потреби во рана фаза — вредноста е во шемата, а не во алатката. Посегнете кон наменска услуга за знаменца (LaunchDarkly, Unleash или слична) кога ќе ви требаат процентуални воведувања, таргетирање корисници или кога тимот е доволно голем што расфрланоста на знаменца бара вистински слој за управување. Почнете со најевтината верзија што ви дозволува да го одвоите „поставено“ од „објавено“, и оставете софистицираноста да расте со вистинската потреба.

Тимовите што испорачуваат смирено не се оние со најмалку грешки. Тоа се оние што изградиле систем во кој грешката стигнува до еден процент од корисниците за десет минути, а не до сите за една недела.

PNK WORKS гради и испорачува софтвер со стратегија за воведување вградена во процесот, а не импровизирана на денот на изданието. Започнете проект.