За щастие, срещнах много малко инженери в кариерата си, които са категорично против непрекъснатото внедряване.

Публикацията Непрекъснати внедрявания != Непрекъснати прекъсвания се появи за първи път на Qvault.

За щастие, срещнах много малко инженери в кариерата си, които са категорично против непрекъснатото внедряване. Въпреки това, срещнах някои и мисля, че тяхното колебание обикновено се корени в мита, че непрекъснатото причинява повече смущения на крайните потребители, отколкото цикълът на пакетно пускане.

Какво е непрекъснато внедряване?

Преди да навлезем в детайлите защо непрекъснатото внедряване (CD) е почти винаги по-добро от пакетните издания, нека дефинираме някои термини. „Определението на Atlassian“ за CD е близко, но ще го модифицирам малко за моите цели. За разлика от тях, не мисля, че CD изисква непрекъснато тестване на интеграцията, но защо не бихте изпълнили тестове, не разбирам.

Непрекъснатото внедряване (CD) е процес на освобождаване на софтуер, който внедрява нови версии в производствена среда, когато са изпълнени определени условия в хранилище на код.

– Me

Например, аз работя много в Kubernetes, така че моят компактдиск често се състои от скрипт за действия на Github, който се изпълнява, когато обединя код в клона main. Скриптът задейства Helm диаграма, която актуализира внедряванията в клъстера.

Има много начини за създаване на добър конвейер на CD, но общото е, че когато се случи задействане (кодът е обединен или е създаден етикет), новото внедряване се изпраща към производството автоматично. Това прави внедряването на код възможно най-безболезнено за разработчика. С идеалното непрекъснато внедряване, изпращането на актуализации не е нищо повече от просто писане на актуализациите.

Непрекъснатото внедряване не причинява ли повече грешки?

No.

„Ускоряване“ е книга, която силно бих препоръчал, която използва казуси от реалния свят, за да покаже положителното въздействие на съвременните DevOps практики. В книгата те сравняват високоефективните софтуерни организации с нискоефективните организации. Според техните данни високоефективните компании:

  • Внедрявайте код ~46 пъти по-често в производството
  • Имате 440 пъти по-бързо време за ангажиране на внедряване
  • Имайте 5 пъти по-нисък процент на неуспешни промени („неуспехите“ са „резултат[и] до влошена услуга или впоследствие изискват коригиране (напр. водят до влошаване на услугата или прекъсване, изискват актуална корекция, връщане назад, корекция напред или корекция). )
  • Имате 170 пъти по-бързо средно време за възстановяване след откази

Докато данните говорят сами за себе си, те имат смисъл и от качествена гледна точка. Наличието на системи, които автоматизират доставката на код, за да отнемат по-малко време, по своята същност няма да създава повече грешки. Това е процесът преди компактдиска, който отговаря за улавянето на грешки. Можем да имаме цяла отделна дискусия относно непрекъснатата интеграция и как това намалява броя на грешките, които достигат до производството, но актът на автоматизиране на внедряването е ортогонален към тази точка.

Непрекъснатите внедрявания не създават повече грешки, но улесняват отстраняването на съществуващи грешки.

Дори и без грешки, непрекъснатите актуализации не са ли разрушителни за крайните потребители?

Може да са, но зависи.

Пример — DotA 2

Аз съм фен на популярната компютърна игра DotA 2. Като потребител на тяхната игра, наистина съм раздразнен от това колко често пускат малки актуализации на корекции. Не е необичайно да играя три или четири игри една след друга и трябва да изтеглям актуализации между игрите. Това е изключително разрушително изживяване, защото, за да актуализирам, трябва да затворя клиента на играта, да изтегля корекцията и да рестартирам играта.

Проблемът с това, което DotA 2 прави, не е, че те (може би) правят CD, а че не са направили изживяването с корекции безпроблемно. Например, те могат да позволят изтегляне на пачове, докато играта е отворена, както Blizzard прави с техния стартер. Като алтернатива, те биха могли да маркират определени видове актуализации като „мързеливи“, например незначителни корекции на грешки няма да изискват рестартиране на играта, те просто ще актуализират следващия път, когато затворите играта.

Пример — Актуализации на потребителския интерфейс

Друго често срещано оплакване е, че при непрекъснато внедряване потребителите ще бъдат постоянно разочаровани, че функциите и оформлението на приложението се променят изпод тях.

Това не е проблем с CD, проблем е с продуктовото планиране.

Само защото непрекъснатото внедряване ни дава инструментите за внедряване на UI/UX промени с по-малко триене, не означава, че трябва да го правим през цялото време. Разбира се, вероятно не е голяма работа да промените формулировката на подсказките или да направите нюанс на червеното малко по-тъмен, но внедряването на необичайно меню и промени на оформлението твърде често е ужасна идея.

Разберете степента на промяна, с която вашите клиенти са добре, и изградете своята пътна карта около това. Отново, това няма нищо общо с вашите процеси на внедряване.

Има само плюс към непрекъснатото внедряване в контекста на UI/UX. Когато откриете печатна грешка в текст за обяснение, можете да поправите грешката в рамките на минути, никой не иска ръчно да изгражда, ssh, изтегля, спира и стартира сървър за нещо толкова тривиално.

Пример — Backend Web

Когато актуализирам код на бекенд сървър, мога да разположа този проект асинхронно без ефект върху крайния потребител. Няма няма причина да не използвате непрекъснато внедряване в такива среди, стига промените да са обратно съвместими.

Обратната съвместимост е от решаващо значение в процеса на непрекъснато внедряване, където множество проекти имат асинхронни цикли на издаване. Безсмислено е да посочваме как обратно несъвместимите промени в REST API ще нарушат съществуващите клиенти. Същите тези проблеми могат да бъдат причинени без непрекъснато внедряване.

Благодаря за четенето, сега вземете курс!

Интересувате ли се от високоплатена работа в областта на технологиите? Намерете интервюта и ги преминете с отличие, след като преминахте моите практически курсове по кодиране.

„Започнете да кодирате сега“

въпроси?

Следвайте ме и ми пишете в Twitter @q_vault, ако имате въпроси или коментари. Ако съм направил грешка в статията, не забравяйте да ме „уведомите“, за да мога да я коригирам!

Абонирайте се за моя бюлетин за повече статии за кодиране, доставени направо във входящата ви кутия.