How to implement Continuous Integration processes using Jenkins .. and staying sane while doing so!

1. CI from scratch with Jenkins
CI от кота нула чрез Jenkins
Борислав Трайков

2. Защо аз ще ви говоря по тази тема?
• Опит с Continuous Build + Test + Deploy с TFS & Octopus Deploy (2013-2015)
• Баш майстор съм на Jenkins инстанция, която обслужва 10 екипа (oт 2016)
• 450 job-а за Continuous Building, Continuous Testing и Continuous Deployment
• Старая се да предоставям яснота и преизползваемост

3. Как да започнем с Jenkins?
Начални очаквания за добавена стойност

4. Как да започнем с Jenkins (технически)
1. Jobs
2. Command line interfaces
3. Plugins
4. Jenkins management
5. Control flow

5. Как да започнем с Jenkins (психически)
1. Време и енергия за комуникация
2. Яснота на изпълнението
3. Възможност за повторяемост
4. Откриване (и комуникиране на) отстраняване на проблеми
5. Отчитане на влиянието на странични фактори
6. Кодът си е код, дори когато е скрипт. Дори когато е shell-ски.

6. Насипни съвети (good practices)
• Четете документация, блогове и issue trackers
•
• Четете и пишете логове. Съхранявайте тези логове!
• Навъртете няколко повторения, за да докажете, че сте готови
• Заделете си време и енергия за непредвидени ситуации

7. Паралелизация?
• Job executors
• Паралелизация на стъпки
• Паралелни извиквания на job-ове
• Много-процесна архитектура

8. Plugins!

9. Control flow plugins (job-to-job)
1. Build Blocker plugin
2. Extended Choice Parameter plugin
3. Extensible Choice Parameter plugin
4. Global Variable String Parameter plugin
5. Hidden Parameter plugin
6. Config File Provider plugin
7. Copy Artifact plugin
8. Multijob plugin
9. Parametrized Trigger plugin
10. Rebuild plugin
11. Matrix Project plugin

10. Control flow plugins (jobs step flow)
1. Conditional BuildStep plugin
2. Text-finder plugin

11. Plugins за допълнителни стъпки на job-ове
1. EnvInject plugin
2. Workspace Cleanup plugin
3. HTML publisher plugin
4. Build Name Setter plugin
5. JUnit plugin
6. Ant plugin
7. Gradle plugin
8. SonarQube Scanner plugin
9. Credentials Binding plugin
10. Performance plugin
11. Allure plugin
12. Powershell plugin

12. Разширяване възможностите на job-овете
1. Git plugin
2. Subversion plugin
3. Timestampler plugin
4. Build Keeper plugin
5. Build timeout plugin
6. Discard Old Build plugin
7. Maven Project plugin

13. Management & Administration plugins
1. CloudBees Folders plugin
2. Martix Authorization Strategy plugin
3. Credentials plugin
4. Job Configuration history plugin
5. Build Trigger Badge plugin
6. Disk Usage plugin
7. Active Directory plugin
8. Bitbucket plugin
9. Windows Slaves plugin

14. Visibility plugins
• Customize Build Now Label
• Green Balls plugin
• Nested View plugin
• Summary Display plugin
• View Job Filters plugin

15. Pipeline
Blue Ocean

16. Цената на управлението на Jenkins сървър
•Възприето КПД
• Налични ресурси – памет, дисково пространство и мрежа
• Осигуряване на достъп + нива на правомощия
• Промени по наличната функционалност
• Обновления на инструментите
• Конфигурация на сървъра

17. Plugin management

18. Jenkins updates – LTS или latest nightly?
• https://jenkins.io/changelog-stable/

19. Пример за непредвидена и неочаквана ситуация

21. Благодаря!
Контакти:
Следващо събитие:
Windows: Kubernetes – past, present and
future
borislav.t.traykov
@turbobobi
borislavtraykov

22. Plugins!

23. Build Blocker plugin

24. Extended Choice Parameter plugin
• Примерът помага да имаме йерархия от drop-down-и. Примерно на коя
среда и на коя машина по-точно искаме нещо да се случи

25. Extensible Choice Parameter plugin
• За когато искаме да дадем насоки за възможните стойности при изпълнение

26. Global Variable String Parameter plugin
• Документацията е достатъчно добра – направо я разгледайте 
Използваме го, за да имаме глобални променливи валидни само за
Jenkins.
Техните стойности се настройват само от Jenkins администратори, така
че има много малък шанс да изчезнат или някой да ги промени по
погрешка/нарочно.

27. Hidden Parameter plugin
• Използваме го когато даден job може да се извика както на ръка (от
некомпетентен персонал), така и по автоматизиран начин.
• Идеята е да има предаваща се променлива, за която човек да не знае
когато пуска job-a на ръка

28. Config File Provider plugin
• За глобални файлове, които да се консумират по различни начини от job-овете.
• Кофтито е, че тези файлове се конфигурират през основния конфигурационен интерфейс на
Jenkins => трябват права за пипане там, където има и много други общи и глобални
(потенциално счупващи работата на останалите колеги) настройки
• За жалост в при update на plugin-а в последните 2-3 версии изтрива файловете, които съм
качил и трябва да ги качвам наново 

29. Copy Artifact plugin
• Позволява ни да предаваме файлове от един джоб на друг.
• Единият job архивира артефактите като част от всяко свое успешно приключване. От там нататък всеки друг job може
да ги поиска.
Артефактите се пазят само на master Jenkins node-a – това си идва с плюсовете и минусите.

30. Multijob plugin (1/2)
• Позволява ни да организираме последователност от други job-ове
(включае други multijobs) + обикновени стъпки. Така можем да опишем
сложен процес, който е разбит на атоми (отделни) job-ове.
Така отделните job-ове могат да се изпълняват и независимо, стига да е
наличен необходимия контекст – обикновено това са входящи
променливи.

31. Multijob plugin (2/2)

32. Parametrized Trigger plugin
• По-долу е пример за паралелно извикване на няколко job-a посредством файл, в
който са запазени стойностите на входящите параметри за всяко едно извикване

33. Rebuild plugin
• Позволява ни да re-run-нем конкретен job execution със същите
входящи параметри, с които оригиналът е бил пуснат.
Всякакви други контекстни (като глобалните) променливи са „на живо“
• Особеност: Ако re-execute-нете job execution, който е бил породен от
SCM trigger (on commit например), и re-execution-ът ще бъде маркиран
като scm trigger. Малък бъг(?) при интеграцията на този плъгин и Build
Trigger Badge plugin-а

34. Matrix Project plugin
• Един много полезен и сложен начин да пуснете едно или двумерна матрица от
изпълнения на едно и също нещо с различни входящи параметри.
Клетките на матрицата се задават предварително при конфигуриране на job-
a.
• За момента го ползваме като едномерна матрица – така пускаме една и съща
задача срещу избран от потребителя набор от параметри (при нас това са dev
среди)
• Всяка клетка на матрицата си има свои служебни workspace папка и job
execution log – поради тази причина понякога изпълненията са по-трудни за
проследяване.

35. Conditional BuildStep plugin
• Позволява ни да изразим различни условия, при които една или
повече стъпки могат да се изпълнят.
С повече от 1 условие, UI-а за редактиране става тегав за
навигиране по вертикала…

36. Text-finder plugin
• Ползваме го, за да следим за грешки, които иначе биха предизвикали
фалшиво позитивно изпълнение на даден job.
Единственият лесен начин, за които знаем за търсене на такива грешки
в текстовата конзола на текущото изпълнение на job-a

37. EnvInject plugin
• Позволява да се инжектират променливи (global variables), които да са
валидни за текущото изпълнение. Това може да се случи преди или по
време на същинското изпълнение на job-a.
Така ние предаваме някакъв state от един джоб на друг ИЛИ
дефинираме/предефинираме глобални променливи за стъпките на job-
a
• Интересно е да се отбележи, че доста plugin-и вътрешно използват
възможностите на EnvInject, така че може да се окажете с доста
променливи

38. Workspace Cleanup plugin
• Манна небесна! Позволява ни да затрием цялата или само част от
работната папка на job-a – преди и/или след като е приключил.
• Хубаво е да знаете, че тази операция има и булево условие, така че
да не се изпълнява всеки път
• Има асинхронен режим, така че предстоящото изпълнение да не
трябва да чака понякога времеемкото триене на целия workspace.
Тогава досегашната workspace директория се приеменува със
служебно име, за да може новото изпълнение да започне възможно
най-скоро.
Едва след това Jenkins се пробва да изтрие вече ненужната и
преименована стара workspace директория.

39. HTML publisher plugin
Използваме го, за да
съхраняваме HTML и текстови
файлове – обикновено като
доклади за работата, свършена
от job-a и инструментите,
извикани от него

40. Build Name Setter plugin
• Докладваме обобщение на контекста на изпълнение на
даден job.
Например коя версия на продукта сме подготвили или
пък кой компонент на коя среда/машина сме качили
(deploy-нали)

41. JUnit plugin
• Jenkins има един единствен вграден начин да разпознава тестови
доклади – на jUnit скапания XML формат. Скапан е, защото никъде не е
описан както трябва и затова хората са reverse-engineer-нали как
работи jUnit plugin-а и от там са направили XSD схема на jUnit
докладите.
Защо ми е важно? Защото не е нужно да ползвам jUnit, за да мога да
правя графика на изпълнение на тестовете, които съм написал –
изпълнение след изпълнение. Така ще мога да имам тази графика в
Jenkins за лесен преглед.

42. Ant plugin
• Позволява да има някакво управление на повече от една ant инстанция,
както и лееееееееко подобрено представяне на ant target-ите в
конзолата на изпълнението на job-a

43. Gradle plugin
• Абсолютно аналогичen на Ant plugin-a, но без лекото подобрение в
представянето на (текстовата) конзола на изпълнение на job-a

44. SonarQube Scanner plugin
• Позволява връзка между Sonar (вече известен като SonarQube) и Jenkins
- за анализ като част от изпълнението на job и след това –
предоставяне на връзка към уеб интерфейса на SonarQube

45. Credentials Binding plugin
• Позволява да ползваме предварително запазени credentials като
прикрити променливи, които можем да достъпим в стъпките на job-a.
Така можем да запазим пароли и auth token-и, към които да се
обръщаме потайно.
Така с този plugin можем да избегнем всякакво hardcode-ване на
пароли в нашите job-ове.

46. Performance plugin
• Jmeter генерира доклади – с този плъгин можем да ги
визуализираме в Jenkins

47. Allure plugin

48. Powershell plugin
• Позволява ни да изпълняваме Powershell скриптове по същия начин, по
който бихме изпълнили Windows batch скриптове.
Това ни развързва ръцете да имаме кажи-речи скриптови възможности
за ползване на .NET framework-а (много сходно с използване на C#)

49. Git plugin
• Позволява ни да си дърпаме кода от remote git repo. Обаче освен това
ни позволява да получим и променливи, с които да работим като това
кой branch или кой commit сме свалили.
Допълнителни възможности, които използваме при клониране:
• Shallow clone – защо да даден job да сваля ПЪЛНО копие на историята на repo-то
след като и последната промяна + текущото състояние на repo-то са напълно
достатъчни за един build job 
• Кой конкретен branch, tag или commit да клонираме

50. Subversion plugin
• Абсолютно аналогичен на Git plugin-a
Понякога е добре да се напомня, че в някои отношения git и svn много
си приличат  Това може да ви е от полза ако за някой клиент се
наложи да преминете към SVN
(да, това може да ви се случи и в 2019та или 2020та година!)

51. Timestampler plugin
• Мега прозаичен и полезен plugin!
Добавя timestamp на всеки ред от текстовата конзола на изпълнението
на job-а. Започва да отчита спрямо началото на изпълнението (00:00).
Така можем лесно да разберем къде колко време отива, особено
когато имаме съмнения, породени от 3rd party инструменти или
забавяне на някои мрежови операции

52. Build Keeper plugin
• Позволява да запазваме конкретни изпълнения на job-ове – решението
се взема по време на текущото изпълнение, както и с отделен бутон –
за вече преминалите изпълнения

53. Build timeout plugin
• Поредният от поредицата „прости, но полезни“ plugin-и. Претърпя
някои разширения в по-новите си версии

54. Discard Old Build plugin
• Основният plugin, който ползваме, за да трием старите изпълнения на
даден job, като отделно настройваме колко изпълнения назад да пазим
артефактите

55. Maven Project plugin
• Както и самият Maven, изключително сложен и мощен plugin, който дава много допълнителна
функционалност свързана с build-ването и реферирането на Maven проекти.
Буквално добавя нов тип job – Maven job, който макар и да прилича на стандартния freestyle job, има
много свои особености.
• Гадината проклета има по-особен вкус на архивиране и рефериране на артефакти – буквално трябва
да се съобразите, че реферирате Maven артефакти, а не обикновени Jenkins такива.
• Maven инсталациите ползвани от Maven job-овете се конфигурират в Global Tools Configuration
секцията от Jenkins мениджмънт панела – аналогично на Ant и Gradle plugin-ите

56. CloudBees Folders plugin
• Един от plugin-ите, които се слагат при Jenkins инсталация по подразбиране
• Готин е с това, че прави папки с job-ове и така дава организираност
• Проблемът е, че тези папки и техните job-ове не участват в различни
филтрирани view-та, така че тук нещата стават по-закътани отколкото при
обикновени job-ове
• Една такава папка е буквално псевдо-job – могат да му се настройват
permissions и си има собствен config.xml

57. Martix Authorization Strategy plugin
• Позволява раздаването на права на матричен принцип
• Предлага и силно гранулирано даване на различни права
• Аз го ползвам на следния принцип:
• Анонимен – може да гледа всичко без секцията за конфигуриране на Jenkins
• Потребители-администратори – могат да правят всичко 
• Authenticated users (демек всички останали) – могат да правят каквото си поискат
но не и секцията за конфигуриране на Jenkins

58. Credentials plugin
• Това е толкова сложен, добре описан и полезен plugin, че има 50
страници user manual, да не говорим за другите 2 manual-a 
• Ние използваме plugin-а като credentials storage за usernames &
passwords.
Реферираме ги за всички случаи, когато трябва да свалим код от
source control repo-тата ни – svn и git
• Този plugin е основата на вече споменатия credentials binding plugin

59. Job Configuration history plugin
• Plugin-ът ни позволява да имаме глобални файлове като Maven settings.xml и най-
обикновени XML-и.
Макар и да звучат готино на теория, не харесвам този подход, защото въпреки че
получаваме глобално-достъпни ресурси в нашите job-ове, тази глобалност ги прави
трудни за проследяване и промяна.
Откъде дойде този XML? Аз как мога да го изпробвам на моята машина преди това?
• Трябва да съм с администраторски права на Jenkins, за да мога да променям тези
глобални файлове, така ли? Точно така! Така един програмист, който „аз тук само да
си пипна каквото ми трябва“ може да ви промени някоя системна настройка на
Jenkins.
• Освен това при последните 2-3 версии на plugin-а, авторите направиха големи
промени, които предизвикаха единственият XML, който ползваме да се изтрива
мистериозно при update на plugin-а 

60. Build Trigger Badge plugin
• Простичък и много добре обяснен в официалната си страница plugin.
Ползваме го точно както е описано – за да знаем каква е била
причината даден job да бъде стартиран.
• В случаите когато job е стартиран ръчно, можем да видим от кого по-
точно само с един mouse hover. Тъй като само login-ати потребители
могат да пускат job-ове (анонимният достъп настроен е само за
гледане), виждайки кой е човекът, обикновено можем да предположим
поради каква причина е пуснал job-a.
При нас най-често срещаната причина е, че не му се чака job-ът да се
изпълни автоматично (и това не е нещо лошо).

61. Disk Usage plugin
• Един от малкото недовършени plugin-и, които ползваме – последната му
версия от 2015та е 0.28
• Позволява ни да следим кой job горе-долу колко място заема – като
workspace folder, а също така и колко място консумират тези папки за
всички job-ове. Може да се изкара и disk consumption trend graph, но
поне на нас досега не ни е трябвал.
• Като цяло не разчитам много на този plugin, защото макар и привидно
полезен, не отчита потребление в някои ситуации – при multi-job-ове,
както и на някои скрити папки като .svn

62. Active Directory plugin и Windows Slaves
plugin
• Събирам ги в една категория тъй като надали ще са ви много
интересни.
• Active Directory plugin-а използваме праволинейно – за да могат всички
потребители да ползват Windows user+pass, за да достъпват Jenkins
• Windows Slaves plugin-ът пък позволява да имаме Jenkins slave
инстанции на Windows машини – също доста праволинейно

63. Green Balls plugin
• Създателят на Jenkins (и Hudson) e японец и в страната на изгряващото
слънце светофарите светят синьо вместо зелено.
Поради тази причина по подразбиране Jenkins показва синьо топче при
успешно изпълнение на job.
Тъй като не съм японец (само съм гледал аниме), а и мениджърите се
успокояват от цвета на парите (хе хе), то зелените топчета са далеч по-
ясен индикатор за нас за успешно приключили job-ове.

64. Customize Build Now Label
• Тъй като бутонът за ръчно пускане на job се казва „Build Now“, обаче
не всеки job случи за build-ване на нещо. Затова ние си пишем име,
което подхожда на действията на текущия job, като например

65. View Job Filters plugin
• Предоставя страшно много възможности за филтриране на това кои
job-ове да участват в дадено view. За момента използваме само
филтъра по регулярен израз:
Тук искаме само „trunk“ build job-овете, т.е. без тези, които могат да
завършват на версията на даден release, като например
“Build_Wombat_API_9.11.7543”

66. Nested View plugin
• Позволява ни да имаме view-та, които да съдържат други view-та. Така можем да имаме
подредба базирана на повече от един признак. В показания по-долу пример имаме nested view
Product3, в което има 3 обикновени view-та, всяко от които използва View Job Filters plugin-а,
да показваме job-овете с определено значение за продукта

67. Summary Display plugin
• Позволява ни да имаме report-и, които да се показват директно в Jenkins – като XML. Как пишем XML-a на
report-а? С мнооооого хитър скрипт (на Powershell). Реално можете да изплюете XML-а с друг тип скрипт или
програмка, която job-ът да пусне и след това да използвате post-build стъпката на този plugin за запазване
на report-a (така става и job artifact, който можете да ползвате в други job-ове)