Този сайт използва бисквитки (cookies). Ако желаете можете да научите повече тук. Разбрах

Новини Технологии и ефективност

Непрекъснатата интеграция води до по-бързи и качествени софтуерни разработки

Целта е да се установи постоянен и автоматизиран начин за изграждане, пакетиране и тестване на приложенията

от , 16 август 2018 0 779 прочитания,

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

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

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

Защо е нужна непрекъсната интеграция (CI)

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

Непрекъснатата интеграция представлява философия за писане на код. Асоциира се с набор от практики, при които екипът от разработчици прави малки промени в кода и проверките в системата за контрол на версиите се извършват относително често.

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

Как работи CI на практика

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

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

Обикновено тези екипи предпочитат качването на кода да се осъществява на отделни клонове на системата. Самите клонове имат кратък живот и след като кодът е проверен, бързо отива в частта с останалите готови парчета.

Процесът на изграждане пък е автоматизиран посредством пакетиране на софтуера, базата данни и останалите компоненти. Например, ако разработвате приложение, базирано на Java, CI ще пакетира всички статични файлове на уеб сървъра като HTML, CSS и JavaScript заедно с Java приложението и останалите скриптове на базата данни.

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

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

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

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

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

След като софтуерът е пакетиран, инструментите за непрекъсната интеграция доставят кода в дадена среда, задействат определени услуги, за доставка, като рестарт на сървърите за приложения и правят автоматични тестове. Тези стъпки са познати като непрекъсната доставка (continuous delivery – CD), а тестването на функционалностите, интегрирани в пълната CI и CD са част от процеса на непрекъснат тестинг.

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

КОМЕНТАРИ ОТ  

Полезни страници
    За нас | Аудитория | Реклама | Контакти | Общи условия | Декларация за поверителност | Политика за бисквитки |
    Действителни собственици на настоящото издание са Иво Георгиев Прокопиев и Теодор Иванов Захов