home.md

@@ -68,6 +68,20 @@ pipeline {
 
 Декларативный пайплайн определен более жестко, и, соответственно, его структура читается лучше.
 
+Общая схема непрерывной интеграции с Jenkins:
+
+1. Сначала разработчик фиксирует код в хранилище исходного кода. Тем временем сервер Jenkins регулярно проверяет наличие изменений в хранилище.
+2. Вскоре после того, как происходит фиксация, сервер Jenkins обнаруживает изменения, произошедшие в репозитории исходного кода. Дженкинс потянет эти изменения и начнет готовить новую сборку.
+3. Если сборка не удалась, соответствующая команда будет уведомлена.
+4. Если сборка прошла успешно, Jenkins развертывает встроенный тестовый сервер.
+5. После тестирования Jenkins генерирует обратную связь и затем уведомляет разработчиков о результатах сборки и тестирования.
+6. Он продолжит проверять хранилище исходного кода на предмет изменений, внесенных в исходный код, и весь процесс будет повторяться.
+
+| До Jenkins | После Jenkins |
+| :---:         | :---:    |
+| Весь исходный код был построен и затем протестирован. Поиск и исправление ошибок в случае сбоя сборки и тестирования было трудным и занимало много времени, что, в свою очередь, замедляло процесс доставки программного обеспечения. | Каждый коммит, сделанный в исходном коде, создается и тестируется. Таким образом, вместо проверки всего исходного кода разработчикам нужно сосредоточиться только на конкретном коммите. Это приводит к частым выпускам нового программного обеспечения.   |
+| Разработчики должны ждать результатов испытаний       | Разработчики знают результат тестирования каждого коммита, сделанного в исходном коде на ходу |
+| Весь процесс ручной | Вам нужно только зафиксировать изменения в исходном коде, и Jenkins автоматизирует остальную часть процесса для вас. |
 
 [Страница с руководством по установке и настройке Jenkins](Страница-с-руководством-по-установке-и-настройке-Jenkins)