Урок за непрекъсната доставка - Изграждане на тръбопровод за непрекъсната доставка с помощта на Jenkins

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

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

• Какво е непрекъсната доставка?
• Видове тестване на софтуер
• Разлика между непрекъснатата интеграция, доставка и внедряване
• Каква е необходимостта от непрекъсната доставка?
• Практическо използване на Jenkins и Tomcat

Нека бързо разберем как работи Непрекъсната доставка.

Какво е непрекъсната доставка?

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

Позволете ми да обясня горната диаграма:

• Автоматизираните скриптове за изграждане ще открият промени в управлението на изходния код (SCM) като Git.
• След като промяната бъде открита, изходният код ще бъде разположен на специален сървър за изграждане, за да се увери, че компилацията не се проваля и всички тестови класове и тестове за интеграция работят добре.
• След това приложението за изграждане е разположено на тестовите сървъри (предпроизводствени сървъри) за потребителски тест за приемане (UAT).
• И накрая, приложението се разполага ръчно на производствените сървъри за освобождаване.

Преди да продължа, ще бъде справедливо, ще ви обясня различните видове тестване.

Видове тестване на софтуер:

Най-общо казано, има два вида тестване:

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

Тестване на Whitebox:

Има два вида тестване, които попадат в тази категория.

какво е pojo клас в Java

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

Тестване на Blackbox:

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

• Функционално / приемно тестване: Той гарантира, че определената функционалност, изисквана в системните изисквания, работи. Прави се, за да се увери, че доставеният продукт отговаря на изискванията и работи както клиентът е очаквал
• Тестване на системата: Той гарантира, че като поставя софтуера в различни среди (напр. Операционни системи), той все още работи.
• Стрес тестване: Той оценява как системата се държи при неблагоприятни условия.
• Бета тестване: Това се прави от крайни потребители, екип извън разработката или публично пускане на пълна предварителна версия на продукта, известна катобетаверсия. Целта на бета тестването е да покрие неочаквани грешки.

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

Разлики между непрекъснатата интеграция, доставка и внедряване:

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

В непрекъснатата интеграция всеки коммиране на код се изгражда и тества, но не е в състояние да бъде освободен. Искам да кажа, че приложението за изграждане не се разгръща автоматично на тестовите сървъри, за да го валидира, използвайки различни видове тестване на Blackbox като - Тестване за приемане от потребителя (UAT).

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

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

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

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

Научете как да създавате CI / CD тръбопроводи с помощта на Jenkins On Cloud

Но въпросът е дали непрекъснатата интеграция е достатъчна.

Защо се нуждаем от непрекъсната доставка?

Нека разберем това с пример.

Представете си, че 80 разработчици работят по голям проект. Те използват конвейери за непрекъсната интеграция, за да улеснят автоматизираните компилации. Знаем, че build включва и Unit Testing. Един ден те решиха да внедрят най-новата версия, която е преминала модулните тестове в тестова среда.

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

Каква може да е очевидната причина за неуспеха?

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

Един възприемчив разработчик предприе интелигентен подход:

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

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

Декларация за проблема:

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

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

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

Решение - тръбопровод за непрекъсната доставка (автоматичен тест за приемане):

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

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

Стига с теорията, сега ще ви покажа как да създадете конвейер за непрекъсната доставка, използвайки Дженкинс.

Тръбопровод за непрекъсната доставка с използване на Jenkins:

Тук ще използвам Дженкинс за създаване на тръбопровод за непрекъсната доставка, който ще включва следните задачи:

Стъпки, включени в демонстрацията:

• Извличане на кода от GitHub
• Компилиране на изходния код
• Тестване на единица и генериране на доклади от теста JUnit
• Опаковане на приложението във WAR файл и разполагане на сървъра на Tomcat

Предварителни условия:

• Машина CentOS 7
• Дженкинс 2.121.1
• Докер
• Tomcat 7

Стъпка - 1 Компилиране на изходния код:

Нека започнем, като първо създадем проект за свободен стил в Дженкинс. Помислете за скрийншота по-долу:

Дайте име на вашия проект и изберете Freestyle Project:

Когато превъртите надолу, ще намерите опция за добавяне на хранилище на изходен код, изберете git и добавете URL адреса на хранилището, в това хранилище има глоба pom.xml, който ще използваме за изграждане на нашия проект. Помислете за скрийншота по-долу:

Сега ще добавим Build Trigger. Изберете опцията SCM за анкета, като цяло ние ще конфигурираме Jenkins да анкетира хранилището на GitHub след всеки 5 минути за промени в кода. Помислете за скрийншота по-долу:

Преди да продължа, позволете ми да ви дам малко въведение в цикъла на изграждане на Maven.

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

Следва списъкът на фазите на изграждане:

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

Мога да изпълня командата по-долу за компилиране на изходния код, модулно тестване и дори опаковане на приложението във военен файл:

mvn чист пакет

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

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

компилиране

Помислете за скрийншота по-долу:

Това ще изтегли изходния код от хранилището на GitHub и ще го компилира (Maven Compile Phase).

Кликнете върху Запазване и стартирайте проекта.

Сега кликнете върху изхода на конзолата, за да видите резултата.

Стъпка - 2 Тестване на единица:

Сега ще създадем още един проект за свободен стил за модулно тестване.

Добавете същия URL адрес на хранилището в раздела за управление на изходния код, както направихме в предишната работа.

Сега в раздела „Buid Trigger“ кликнете върху „изграждане след изграждане на други проекти“. Там въведете името на предишния проект, където компилираме изходния код, и можете да изберете някоя от следните опции:

• Задействайте само ако компилацията е стабилна
• Задействайте дори ако компилацията е нестабилна
• Задействайте дори ако компилацията се провали

Мисля, че горните опции са доста обяснителни, така че изберете някоя. Помислете за скрийншота по-долу:

В раздела 'Изграждане' кликнете върху извикване на цели на maven от най-високо ниво и използвайте командата по-долу:

тест

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

Фактически стандартът за тестово отчитане в света на Java е XML формат, използван от JUnit. Този формат се използва и от много други инструменти за тестване на Java, като TestNG, Spock и Easyb. Дженкинс разбира този формат, така че ако вашата компилация дава резултати от теста JUnit XML, Дженкинс може да генерира хубави графични отчети за теста и статистика за резултатите от теста с течение на времето, а също така да ви позволи да видите подробностите за всякакви неуспехи на теста. Дженкинс също така следи колко дълго отнемат тестовете ви, както в световен мащаб, така и за всеки тест - това може да ви бъде полезно, ако трябва да проследите проблемите с производителността.

Следващото нещо, което трябва да направим, е да накараме Дженкинс да следи нашите модулни тестове.

Отидете в секцията Действия след изграждане и поставете отметка в квадратчето „Публикуване на отчета за резултатите от теста на JUnit“. Когато Maven изпълнява модулни тестове в проект, той автоматично генерира XML тестови отчети в директория, наречена surefire-reports. Така че въведете „** / target / surefire-reports / *. Xml“ в полето „XML за отчет на теста“. Двете звездички в началото на пътя („**”) са най-добрата практика за по-стабилна конфигурация: те позволяват на Дженкинс да намери целевата директория, независимо как сме конфигурирали Дженкинс да проверява изходния код.

какво е isinstance в python

** / target / surefire-reports / *. xml

Отново го запазете и кликнете върху Build Now.

Сега отчетът JUnit се записва в / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-поведение.

В таблото на Jenkinsможете също да забележите резултатите от теста:

Стъпка - 3 Създаване на WAR файл и внедряване на сървъра Tomcat:

Следващата стъпка е да опаковаме нашето приложение във WAR файл и да го разположим на сървъра Tomcat за тест за приемане от потребителя.

Създайте още един проект за свободен стил и добавете URL адреса на хранилището на изходния код.

След това в раздела за задействане на изграждане изберете изграждане, когато се изграждат други проекти, разгледайте екранната снимка по-долу:

По принцип след тестовата работа фазата на внедряване ще започне автоматично.

В раздела за изграждане изберете скрипта на черупката. Въведете командата по-долу, за да опаковате приложението във WAR файл:

mvn пакет

Следващата стъпка е да разположите този WAR файл в Tomcatсървър. В раздела „Действия след изграждане“ изберете разполагане на war / ear към контейнер. Тук дайте пътя към военния файл и контекстния път. Помислете за скрийншота по-долу:

Изберете идентификационните данни на Tomcat и забележете горната екранна снимка. Освен това трябва да дадете URL адреса на вашия сървър Tomcat.

За да добавите идентификационни данни в Jenkins, щракнете върху опцията за идентификационни данни на таблото за управление на Jenkins.

Кликнете върху Система и изберете глобални идентификационни данни.

След това ще намерите опция за добавяне на идентификационните данни. Кликнете върху него и добавете идентификационни данни.

Добавете идентификационните данни на Tomcat, помислете за скрийншота по-долу.

Щракнете върху OK.

Сега във вашата конфигурация на проекта добавете идентификационните данни на tomcat, които сте вмъкнали в предишната стъпка.

Кликнете върху Save и след това изберете Build Now.

Отидете на вашия URL адрес на tomcat, с контекстния път, в моя случай това е http: // localhost: 8081. Сега добавете контекстния път в края, помислете за снимката на екрана по-долу:

Връзка - http: // localhost: 8081 / gof

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

Сега създайте изглед на конвейер, помислете за скрийншота по-долу:

Щракнете върху иконата плюс, за да създадете нов изглед.

Конфигурирайте конвейера по начина, по който искате, помислете за скрийншота по-долу:

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

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

Така че ние сме в състояние непрекъснато да разгръщаме нашето приложение на тестовия сървър за тест за приемане от потребителя (UAT).

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

За да изградите CI / CD тръбопроводи, трябва да овладеете голямо разнообразие от умения Овладейте необходимите умения за DevOps сега