Разбиране на непрекъсната интеграция и непрекъснато внедряване

Чух CI / CD, но не сте сигурни какво представлява?


В идеалния случай софтуерните инженери са наети да пишат код, който трябва да бъде изпратен до производствена среда, така че бизнесът, който се нуждае от продукта, да може да се възползва от него. За да задоволите бизнеса (често наричан потребители / клиенти), е от съществено значение продуктите да не съдържат грешки.

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

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

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

Какво е решението?

Непрекъсната интеграция

https://www.youtube.com/watch?v=HnWuIjUw_Q8

За да предотвратя описаните по-горе сценарии; инженерните екипи могат да приемат практиката, наречена непрекъсната интеграция – както подсказва името, това включва непрекъсната интеграция на промените в кода, направени от разработчиците в споделения клон / хранилище. Кодът, който трябва да бъде интегриран, трябва да премине проверен тест, за да се гарантира, че не нарушава приложението. Едва когато тестът премине, той е интегриран

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

Преди да бъде интегрирана тази нова промяна, трябва да се извършат поредица от тестове.

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

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

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

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

Видове тестове

При писане на тестове, които ще бъдат част от процеса на интеграция, ето някои от тях, които могат да бъдат реализирани в процеса:

  • Интеграция – тя комбинира отделни единици от софтуера и ги тества като група.
  • Единица – тества за отделни единици или компоненти на софтуера като методи или функции.
  • UI – твърди, че софтуерът работи добре от гледна точка на потребителя.
  • Приемане – тестове, на които софтуерът отговаря на бизнес изискванията.

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

Инструменти за непрекъсната интеграция

Без да навлизате в дълбочина, ето инструменти, които можете да започнете да използвате във вашите текущи или нови проекти;

  • Травис CI – известен в света с отворен код и ви обещава безпроблемно да тествате кода си за минути.
  • Кръг CI – Ви осигурява мощност, гъвкавост и контрол за автоматизиране на вашия тръбопровод от контрол до внедряване.
  • Дженкинс – осигурява стотици плъгини за поддръжка на изграждане, внедряване и автоматизиране на всеки проект.

Ако сте нов за Дженкинс, тогава бих предложил да вземете това Удеми курс да научите CI с Java и .NET.

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

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

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

Както в случая на непрекъсната интеграция, когато се използва непрекъснато внедряване, се създават автоматизирани тестове и проверки, за да се гарантира, че ново интегрираните промени са проверени. Разгръщането се случва само когато преминат тези тестове.

За да може екипът да се възползва от практиката на непрекъснато разгръщане, той трябва да има следното;

  • Автоматизираното тестване е основната основа на всички непрекъснати инженерни практики. В случай на непрекъснато внедряване, кодът, който трябва да бъде разгърнат, трябва да отговаря на стандарта, който екипът е въвел, за това, което възнамерява да изведе на крайните потребители. В идеалния случай, ако нова промяна е под прага, тестът трябва да се провали и да не се интегрира. Друго, тя става интегрирана.
  • Въпреки автоматичните тестове да се върнат назад, възможно е някои грешки да се промъкнат в производствената среда. За това е необходимо екипът да може да отмени извършената промяна – да отмените разгръщане. Това трябва да върне производствения код на това, което беше преди новата промяна.
  • Системите за мониторинг са необходими, за да се следят промените, които са били изтласкани към производствената среда. Ето как екипът може да проследява грешки, които потребителите срещат при използване на внедрените промени.

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

заключение

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

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

Ако сте разработчик и се интересувате от изучаването на CI / CD, проверете това блестящ курс.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map