Как пускаме софтуерни корекции в GitLab

В GitLab обработваме софтуерни корекции по два начина: ръчно и автоматично. Прочетете, за да научите за работата на мениджъра на версиите за създаване и доставяне на важни актуализации чрез автоматизирано внедряване на gitlab.com, както и корекции, с които потребителите да работят в собствените си инсталации.

Препоръчвам да зададете напомняне на вашия смарт часовник: всеки месец на 22-ри, потребителите, работещи с GitLab в техните съоръжения, могат да видят актуализации на текущата версия на нашия продукт. Месечното издание съдържа нови функции, разработки на съществуващи и често показва крайния резултат от заявки на общността за инструменти или сливания.

Но, както показва практиката, разработката на софтуер рядко е без недостатъци. Когато бъде открита грешка или уязвимост в сигурността, мениджърът на версиите в екипа за доставка създава корекция за нашите потребители с техните инсталации. Gitlab.com се актуализира по време на процеса на CD. Наричаме този процес на CD автоматично внедряване, за да избегнем объркване с функцията CD в GitLab. Този процес може да включва предложения от заявки за изтегляне, изпратени от потребители, клиенти и нашия вътрешен екип за разработка, така че решаването на скучния проблем с пускането на кръпки се решава по два много различни начина.

«Ние гарантираме, че всичко, което разработчиците правят, се внедрява във всички среди всеки ден, преди да го разпространим в GitLab.com“, обяснява Марин Янковки, старши технически мениджър, отдел „Инфраструктура“. "Мислете за изданията за вашите инсталации като моментни снимки за внедрявания на gitlab.com, за които сме добавили отделни стъпки за създаване на пакет, така че нашите потребители да могат да го използват за инсталиране на своите инсталации".

Независимо от грешката или уязвимостта, клиентите на gitlab.com ще получат поправки скоро след публикуването им, което е предимство на автоматизирания процес на CD. Корекциите за потребители със собствени инсталации изискват отделна подготовка от мениджъра на версиите.

Екипът за доставка работи усилено, за да автоматизира повечето от процесите, включени в създаването на версии за намаляване MTTP (средно време до производство, т.е. време, изразходвано за производство), периодът от време от обработката на заявка за сливане от разработчика до внедряването на gitlab.com.

«Целта на екипа за доставка е да се уверим, че можем да се движим по-бързо като компания или поне да накараме доставчиците да работят по-бързо, нали?, казва Марин.

Както клиентите на gitlab.com, така и потребителите на техните инсталации се възползват от усилията на екипа за доставка за намаляване на времето за цикъл и ускоряване на внедряването. В тази статия ще обясним приликите и разликите между тези два метода. въпроси, а също така ще опишем как нашият екип за доставка подготвя корекции за потребители, работещи на място, и как поддържаме gitlab.com актуален с помощта на автоматизирано внедряване.

Какво прави мениджърът за освобождаване?

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

Изданията за самоинсталация и изданията на gitlab.com използват подобни работни процеси, но се изпълняват по различно време, обяснява Марин.

Първо и най-важното, мениджърът на версиите, независимо от типа версия, гарантира, че GitLab е наличен и защитен от момента, в който приложението е стартирано на gitlab.com, включително гарантира, че същите проблеми не попадат в инфраструктурата на клиентите с техните собствени мощности.

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

Мениджърът на версиите трябва да реши дали да подготви корекция или кога да я разположи - и това силно зависи от контекста на ситуацията, "междувременно машините не са толкова добри в управлението на контекста, колкото хората“, казва Марин.

Всичко е свързано с поправките

Какво представляват пачовете и защо са ни необходими?

Мениджърът на версиите решава дали да пусне корекция въз основа на сериозността на грешката.

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

Въпреки това, уязвимостите S1 или S2 означават, че потребителят не трябва да актуализира до най-новата версия, или има значителна грешка, която засяга работния процес на потребителя. Ако са включени в тракера, много потребители са се сблъскали с тях, така че мениджърът на версиите веднага започва да подготвя корекция.

След като корекцията за уязвимости S1 или S2 е готова, мениджърът на версиите започва да пуска корекцията.

Например корекцията GitLab 12.10.1 беше създадена, след като бяха идентифицирани няколко проблема с блокиране и разработчиците поправиха основния проблем, който ги причиняваше. Release manager оцени правилността на зададените нива на сериозност и след потвърждение стартира процесът на пускане на корекция, която беше готова в рамките на XNUMX часа след откриването на проблемите с блокиране.

Когато се натрупат много S4, S3 и S2, мениджърът на версиите преглежда контекста, за да определи спешността на пускането на корекция, и когато се достигне определен брой от тях, всички те се комбинират и освобождават. Корекциите след издаването или актуализациите на защитата са обобщени в публикации в блогове.

Как мениджърът на версии създава корекции

Ние използваме GitLab CI и други функции като нашите ChatOps за генериране на корекции. Мениджърът на версии задейства пускането на корекцията, като активира екипа на ChatOps в нашия вътрешен канал #releases в Slack.

/chatops run release prepare 12.10.1

ChatOps работи в рамките на Slack, за да задейства различни събития, които след това се обработват и изпълняват от GitLab. Например, екипът за доставка настрои ChatOps, за да автоматизира различни неща за пускане на пачове.

След като мениджърът на версиите стартира екипа на ChatOps в Slack, останалата част от работата се извършва автоматично в GitLab с помощта на CICD. Има двупосочна комуникация между ChatOps в Slack и GitLab по време на процеса на издаване, тъй като мениджърът на изданията активира някои от основните стъпки в процеса.

Видеото по-долу показва техническия процес на подготовка на корекция за GitLab.

Как работи автоматичното внедряване на gitlab.com

Процесът и инструментите, използвани за актуализиране на gitlab.com, са подобни на тези, използвани за създаване на корекции. Актуализирането на gitlab.com изисква по-малко ръчна работа от гледна точка на мениджъра на версиите.

Вместо да изпълняваме внедрявания с помощта на ChatOps, ние използваме CI функции, напр. планирани тръбопроводи, с който мениджърът на освобождаването може да планира определени действия, които да бъдат извършени в необходимото време. Вместо ръчен процес, има тръбопровод, който се изпълнява периодично веднъж на час, който изтегля новите промени, направени в проектите на GitLab, пакетира ги и планира внедряването и автоматично изпълнява тестване, QA и други необходими стъпки.

„Така че имаме много внедрявания, работещи в различни среди преди gitlab.com, и след като тези среди са в добра форма и тестването покаже добри резултати, мениджърът на версиите започва действията по внедряване на gitlab.com“, казва Марин.

Технологията CICD за поддържане на актуализации на gitlab.com автоматизира целия процес до точката, в която мениджърът на версиите трябва ръчно да стартира внедряването на производствената среда в gitlab.com.

Марин навлиза в подробности за процеса на актуализиране на gitlab.com във видеото по-долу.

Какво друго прави екипът за доставка?

Основната разлика между процесите на актуализиране на gitlab.com и пускането на корекции на клиентите е, че последният процес изисква повече време и повече ръчна работа от мениджъра на версиите.

„Понякога забавяме пускането на корекции на клиенти с техните инсталации поради докладвани проблеми, проблеми с инструментите и защото има много нюанси, които трябва да се вземат предвид при пускането на един пач“, казва Марин.

Една от краткосрочните цели на екипа за доставка е да намали обема на ръчната работа от страна на мениджъра на версиите, за да ускори освобождаването. Екипът работи за опростяване, рационализиране и автоматизиране на процеса на издаване, което ще помогне да се получат корекции на проблеми с ниска сериозност (S3 и S4, прибл. преводач). Фокусирането върху скоростта е ключов показател за ефективност: необходимо е да се намали MTTP - времето от получаване на заявка за сливане до внедряване на резултата в gitlab.com - от сегашните 50 часа на 8 часа.

Екипът за доставка също работи върху мигрирането на gitlab.com към базирана на Kubernetes инфраструктура.

NB на редактора: Ако вече сте чували за технологията Kubernetes (и не се съмнявам, че сте), но все още не сте я докоснали с ръцете си, препоръчвам ви да участвате в онлайн интензивни курсове База Kubernetes, който ще се проведе на 28-30 септември и Kubernetes Mega, който ще се проведе от 14 до 16 октомври. Това ще ви позволи уверено да навигирате и да работите с технологията.

Това са два подхода, които преследват една и съща цел: бърза доставка на актуализации, както за gitlab.com, така и за клиентите в техните съоръжения.

Някакви идеи или препоръки за нас?

Всеки е добре дошъл да допринесе за GitLab и ние приветстваме обратната връзка от нашите читатели. Ако имате някакви идеи за нашия екип за доставка, не се колебайте създайте приложение с предизвестие team: Delivery.

Източник: www.habr.com