5 често срещани клопки на CI / CD - и как да ги избегнете

Devops може да е един от най-мрачните термини в разработването на софтуер, но повечето от нас са съгласни, че пет дейности правят това, което е: непрекъсната интеграция, непрекъсната доставка, облачна инфраструктура, автоматизация на тестове и управление на конфигурацията. Ако правите тези пет неща, правите devops. Ясно е, че и петте са важни, за да се оправиш, но твърде лесно е да се объркаш. По-специално, непрекъснатата интеграция и непрекъснатата доставка (CI / CD) могат да бъдат най-трудните ходове на devops за усвояване.

Непрекъснатата интеграция (CI) е процес, при който разработчиците и тестерите съвместно валидират нов код. Традиционно разработчиците пишат код и го интегрират веднъж месечно за тестване. Това беше неефективно - грешка в кода отпреди четири седмици може да принуди разработчиците да преразгледат кода, написан преди една седмица. За да се преодолее този проблем, CI зависи от автоматизацията за непрекъснато интегриране и тестване на код. Scrum екипите, използващи CI код за ангажиране най-малко ежедневно, докато повечето от тях ангажират код за всяка въведена промяна.

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

По този начин CI / CD е процес за непрекъснато разработване, тестване и доставка на нов код. Някои компании като Facebook и Netflix използват CI / CD, за да завършат 10 или повече издания на седмица. Други компании се борят да постигнат това темпо, защото се поддават на една или повече от петте клопки, които ще обсъдя следващата.

CI / CD клопка # 1: Първо автоматизиране на грешните процеси

Този капан има тенденция да удря организации, които преминават от развитие на водопада към девапс. Новите организации имат предимството да внедрят CI / CD от нулата. Съществуващите компании трябва да преминат постепенно от ръчно до високо автоматизирано развитие. Пълният преход може да отнеме няколко месеца, което означава, че трябва да бъдете итеративни в начина, по който приемате CI / CD.

Когато попитате: „Трябва ли това да се автоматизира сега?“ преминете през следния контролен списък:

  1. Колко често се повтаря процесът или сценарият?
  2. Колко е дълъг процесът?
  3. Какви хора и зависими ресурси са включени в процеса? Те причиняват ли закъснения в CI / CD?
  4. Предразположен ли е процесът към грешки, ако не е автоматизиран?
  5. Каква е спешността при автоматизирането на процеса?

Използвайки този контролен списък, можете да дадете приоритет на стъпките в изпълнението на CI / CD. Първо и най-важно, автоматизирайте процеса за компилиране на код. В идеалния случай ще интегрирате кода няколко пъти на ден (1). Ръчно процесът отнема от няколко минути до няколко часа (2). Това спира изхода, докато компилаторът не завърши задачата (3). Също така е податлив на човешки грешки (4) и тъй като CI / CD е мечта на тръбата без автоматизирана интеграция, това е спешно (5).

Можем да пуснем същия контролен списък при тестване. Докато преминавате към CI / CD, може да се чудите: Трябва ли да автоматизираме първо функционалното тестване или тестването на потребителския интерфейс? И двете ще се повтарят поне веднъж на ден (1). И двете могат да отнемат два до три часа за средно голямо приложение (2). Но те включват множество зависимости (3). Ако автоматизирате функционално тестване, може да не се наложи да актуализирате скрипта за автоматизация толкова често. Потребителският интерфейс, от друга страна, често се променя и поради това изисква чести промени в скрипта. Въпреки че и двете са склонни към грешки (4), трябва да дадете приоритет на функционалното тестване преди тестването на потребителския интерфейс, за да използвате най-добре ресурсите си (5).

Нека направим това още веднъж с процеса на създаване на среди. Този сценарий се повтаря често, само ако сте под наем или изпитвате сериозни отклонения (1). Това е доста отнемащ време процес, който може да отнеме няколко часа, ако не и дни (2). Новите членове на екипа не могат да направят нищо полезно без среда, така че очевидно има зависимост и забавяне (3). Не бих казал, че процесът е склонен към грешки (4), така че все още ли е спешен (5)? Наклонявам се към да, но все пак бих дал първо приоритет на интеграцията и функционалното тестване.

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

CI / CD подводник # 2: Объркващо непрекъснато внедряване за непрекъсната доставка

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

Компаниите вярват, че ако не практикуват непрекъснато внедряване, те не правят CD. Те не успяват да направят разлика между непрекъснато внедряване и непрекъсната доставка.

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

Кодовата база винаги е на ниво качество, което е безопасно за пускане. Кога да пуснете кодовата база за производство е бизнес решение.

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

CI / CD ловушка # 3: Липса на значими табла за управление и показатели

При внедряванията на CI / CD екипът за скрам може да създаде табло, преди членовете да разберат какво трябва да проследяват. В резултат на това екипът става жертва на логична заблуда: „Това са показателите, които имаме, така че те трябва да са важни.“ Вместо това направете прогресивна оценка, преди да проектирате табло.

Различните членове на ИТ организация и дори различни членове на скрам екип имат различни приоритети. Например хората в мрежовия оперативен център (NOC) обичат червените, жълтите и зелените индикатори. Такива табла на светофара позволяват на служителите на NOC да различават проблемите, без да четат плътен текст или да облагат своите аналитични способности. Светофарите помагат да се направят стотици сървъри управляеми.

Може да се изкушите да използвате табло за управление на светофара и за CI / CD. Грийн, ние сме на път. Жълто, ние сме на път, но имаме план да се справим с това. Червено, ние сме на път и вероятно ще трябва да променим целите си.

Това табло за управление вероятно е полезно за scrum master, но какво ще кажете за вицепрезидента на разработката или техническия директор? Ако отборен екип има 350 часа работа за двуседмичен спринт и 10-те му членове отговарят по 35 часа всеки, те ще получат съответния брой сюжетни точки. Висшето ръководство може да се интересува по-малко от състоянието на сюжетни точки и да бъде по-любопитно относно степента на „изгаряне“: скоростта на изпълнение на задачата. Носят ли членовете на екипа своите товари? Колко бързо Подобряват ли се с времето?

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

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

Това са съображенията, които трябва да се изследват при прогресивна оценка. Те илюстрират колко сложно е да се направи полезно табло за управление CI / CD и да се зарадват всички. Твърде често най-гласовитият член на екипа отвлича процеса, а други се чувстват разочаровани, че таблото отговаря само на предпочитанията на един човек. Слушайте всички.  

CI / CD подводник # 4: Липса на координация между непрекъснатата интеграция и непрекъсната доставка

Тази клопка ни връща към нашата консенсусна дефиниция на devops, която твърди, че непрекъснатата интеграция и непрекъснатата доставка са два различни елемента. CI подава CD. Внедряването на приличен конвейер за непрекъсната интеграция и пълна система за непрекъсната доставка отнема месеци и изисква сътрудничество. Осигуряването на качеството, екипът на devops, оперативните инженери, scrum-майсторите - всички трябва да допринесат. Може би най-трудният аспект на CI / CD е този човешки фактор, а не някакво техническо предизвикателство, което сме обсъждали. Както не можете да програмирате здравословна връзка между двама души, така не можете да автоматизирате сътрудничеството и комуникацията.

За да прецените това ниво на координация, сравнете своя CI / CD процес с най-добрите в бизнеса. Компании като Netflix могат да завършат интеграцията, тестването и доставката в рамките на два до три часа. Те създадоха система, която предава код от ръка на ръка без нерешителност и дискусия. Не, това не е 100 процента автоматизирано, защото това е невъзможно с настоящите технологии.

Капака на CI / CD # 5: Балансиране на честотата на изпълнение на задачи за непрекъсната интеграция и използване на ресурси

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

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

Дръжте целта в очите

Докато ровим в клопките на CI / CD - заедно с цялата му езотерична терминология - е лесно да загубим от поглед защо това има значение. В крайна сметка CI / CD е от съществено значение, тъй като отговаря на бизнес целите.

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

Просто казано, капаните на CI / CD си струва да бъдат прегледани, защото са заложени милиарди долари. Въпреки че не ви предлагам да добавяте индикатор за акции или тракер за преглед на App Store към вашето табло за управление на CI / CD, настоявам ви да останете наясно с това. Много зависи от детайлите на CI / CD.

Зубин Ирани е съосновател и главен изпълнителен директор на cPrime, консултантска компания с пълен набор от услуги, която осъществява гъвкави трансформации и предлага гъвкави решения за повече от 50 фирми от Fortune 100 и много от най-големите работодатели в Силициевата долина.

Форумът New Tech предоставя място за изследване и обсъждане на нововъзникващите корпоративни технологии в безпрецедентна дълбочина и широчина. Изборът е субективен, базиран на нашия избор на технологиите, които смятаме, че са важни и представляват най-голям интерес за читателите. не приема маркетингово обезпечение за публикуване и си запазва правото да редактира цялото съдържание. Изпращайте всички запитвания на [email protected]