Чухте CI/CD, но не сте сигурни какво е?
В идеалния случай софтуерните инженери се наемат да напишат код, който трябва да бъде изпратен в производствена среда, така че бизнесът, който се нуждае от продукта, да може да го използва. За да удовлетворите бизнеса (често наричан потребители/клиенти), от съществено значение е продуктите да са без грешки.
Типичният подход, следван от софтуерните инженери, е да работят в клонове и да създават заявка за изтегляне, която актуализира главния клон с новата актуализация, която е направена. Възприехме практиката да пишем тестове като средство за гарантиране, че новите промени не въвеждат грешки. Когато разработчиците работят върху функция в повечето случаи, те често не създават заявка за изтегляне, докато не са напълно готови с функцията. Това, което се случва, когато са готови, е това;
- Те прекарват много време в опити да актуализират кодовата си база с промените, настъпили в производствения клон, докато са работили.
- Правейки това, те трябва да коригират поредица от конфликти при сливане.
- Съществува и възможност те да нарушат производствения клон, което впоследствие ще засегне онези, които изтеглят от клона, преди проблемът да бъде видян и отстранен.
Ако някога сте попадали в тази ситуация, ще се съгласите, че това може да бъде болка – никой не обича да прекарва работния си ден по този начин.
Какво е решението?
Съдържание
Непрекъсната интеграция
За да предотвратите сценариите, които посочих по-горе; инженерните екипи могат да приемат практиката, наречена непрекъсната интеграция – както подсказва името, тя включва непрекъсната интеграция на промените в кода, направени от разработчиците в споделения клон/хранилище. Кодът, който ще бъде интегриран, трябва да бъде подложен на проверен тест, за да се гарантира, че не нарушава приложението. Едва когато тестът премине, той се интегрира
За да разберем това, нека си представим сценарий от реалния живот, при който има екип от 10 разработчици. Тези разработчици създават локален клон, в който пишат код за внедряване на определени функции. Вместо да изпращат заявки за изтегляне, когато са напълно готови с функцията, те избират да изпращат заявки за изтегляне, тъй като правят малки промени. Пример за такава промяна ще бъде създаването на нов модал, ако приемем, че разработчикът работи върху функция, която позволява на потребителите да управляват отделни задачи в приложението. Вместо да чака, докато функцията на задачата бъде завършена, за да се придържа към непрекъснат модел на интеграция, разработчикът натиска тази малка промяна (в сравнение с това, върху което работи) и създава заявка за изтегляне за сливане с кода.
Преди тази нова промяна да бъде интегрирана, трябва да се извършат серия от тестове.
Екипите за софтуерно инженерство използват инструменти като Травис CI за създаване на тези интеграционни процеси и тестове. С инструменти като тези тестовете са автоматизирани, така че да се изпълняват веднага щом се изпрати заявка за изтегляне към целевия клон, избран по време на настройката.
Резултатите от тестовете се генерират и разработчикът, който е създал заявките за изтегляне, може да види резултатите и да направи необходимите промени. Ползите от придържането към този модел на интегриране на код възможно най-малко и наличието на проверен тест за изпълнение са;
- Става възможно участващият екип да разбере какво е причинило неуспеха на процеса на изграждане или теста. Това намалява възможността за изпращане на грешка в производството.
- Ако екипът автоматизира процеса, те ще имат лукса на времето да се съсредоточат върху продуктивността.
Важното, което трябва да се отбележи в тази практика е, че тя насърчава екипа често да изпраща код към главния клон. Това ще бъде неефективно, ако други членове на екипа не изтеглят от главния клон, за да актуализират своето локално хранилище.
Видове тестове
При писане на тестове, които ще бъдат част от процеса на интегриране, ето някои от тях, които могат да бъдат внедрени в процеса:
- Интеграция – обединява отделни единици от софтуера и ги тества като група.
- Единица – тества отделни единици или компоненти на софтуера като методи или функции.
- UI – твърди, че софтуерът работи добре от гледна точка на потребителя.
- Приемане – тестове дали софтуерът отговаря на бизнес изискванията.
Важно е да се отбележи, че не е необходимо да тествате всички тези, тъй като някои от тях може вече да са включени в кода, написан от разработчика.
Инструменти за непрекъсната интеграция
Без да навлизаме в дълбочина, ето инструменти, които можете да започнете да използвате във вашите текущи или нови проекти;
- Травис CI – известен в света на отворения код и ви обещава, че кодът ви ще бъде тестван безпроблемно за минути.
- Кръг CI – осигурява ви мощност, гъвкавост и контрол за автоматизиране на вашия тръбопровод от контрола до внедряването.
- Дженкинс – предоставя стотици плъгини в подкрепа на изграждането, внедряването и автоматизирането на всеки проект.
Ако сте нови за Дженкинс, тогава бих ви предложил да вземете това Курс по Udemy да научите CI с Java и .NET.
Непрекъснато внедряване
Каква полза ще има, ако създадената от вас функция стои в хранилището седмици или месеци, преди да бъде разгърната в производствената среда. Доколкото инженерните екипи могат да работят за интегриране на малки промени в основния клон, когато това се случи, те могат също да прокарат тези промени в производствената среда възможно най-скоро.
Целта при практикуване на непрекъснато внедряване е направените промени да се сведат до потребителите веднага щом разработчиците интегрират тези промени в основния клон.
Както в случая на непрекъсната интеграция, когато се използва непрекъснато внедряване, се настройват автоматизирани тестове и проверки, за да се гарантира, че новите интегрирани промени са проверени. Внедряването става само когато тези тестове преминат успешно.
За да може един екип да се възползва от практиката на непрекъснато внедряване, той трябва да разполага със следното;
- Автоматизираното тестване е основният гръбнак на всички непрекъснати инженерни практики. В случай на непрекъснато внедряване, кодът, който ще бъде внедрен, трябва да отговаря на стандарта, който екипът е въвел за това, което възнамеряват да прокарат на крайните потребители. В идеалния случай, ако нова промяна е под прага, тестът трябва да се провали и да не бъде интегриран. В противен случай става интегриран.
- Въпреки наличието на автоматизирани тестове последователно, е възможно някои грешки да се промъкнат в производствената среда. За това е необходимо екипът да може да отмени направена промяна – отмяна на внедряване. Това трябва да върне производствения код до това, което беше преди да бъде направена новата промяна.
- Необходими са системи за наблюдение, за да следят промените, които са били насочени към производствената среда. Това е начинът, по който екипът може да проследява грешки, които потребителите срещат, когато използват въведените промени.
Споменатите инструменти за непрекъсната интеграция ви предоставят и функционалността за настройка на система за непрекъснато внедряване. Има много от тях, за които можете също да прочетете.
Заключение
Производителността на екипа за разработка е жизненоважна за успеха на бизнеса. За да се гарантира, че са продуктивни, трябва да се възприемат практики, които насърчават това. Непрекъснатата интеграция и внедряване са примери за такива практики.
С непрекъсната интеграция екипите могат да прокарват възможно най-много код всеки ден. С постигането на това става лесно внедряването на новодобавените промени към потребителя възможно най-скоро. Внедряването на тези промени прави възможно получаването на обратна връзка от потребителите. В крайна сметка бизнесът ще може да прави иновации въз основа на получената обратна връзка, което е печелившо за всички.
Можете също така да научите как да увеличавате и оптимизирате CI/CD.
Ако сте разработчик и се интересувате от изучаване на CI/CD, вижте това брилянтен курс.
Приятно ви е да прочетете статията? Какво ще кажете за споделяне със света?