Create intro.md (qcha#181)

* Create intro.md for CI
* Github Actions CI example

ci/github_ci.md

@@ -0,0 +1,71 @@
+# Continuous Integration с помощью Github Actions
+
+## Введение 
+В [этой](./intro.md) статье было рассмотрено, что такое CI и зачем он нужен. Здесь предлагаю рассмотреть пример того, как можно настроить CI с помощью [Github Actions](https://docs.github.com/ru/actions) - платформы непрерывной интеграции и доставки, которая позволяет выстраивать такие процессы, как автоматизация сборки, тестирования и развертывания.
+
+Мы будем использовать Github Actions, чтобы автоматически тестировать наш проект при внесении изменений в удаленный репозиторий. Ожидаемый результат - все тесты пройдут корректно, и задача завершится успешно. Если тесты не пройдут, то мы должны получить подробную информацию о том, какой тест упал и почему. 
+
+## Проект
+Во-первых, нужно взять какой-то проект, на котором мы хотим выстроить процессы. Наша цель это запустить юнит-тесты и убедиться, что ничего не валится.
+Для примера возьмем [этот](https://github.com/qcha/ci-gradle-example) проект на Java с Gradle.
+
+Это простая библиотека, содержащая абстрактный класс фигуры с методами получения периметра и площади, а также имплементацию этого класса в виде круга. У круга есть поле `radius`, которое должно быть строго положительным. Если это не так, то будет выброшено исключение. 
+
+Напишем юнит-тесты для круга на следующие ситуации:
+* Исключение выбрасывается при неположительном радиусе
+* Исключение не выбрасывается при положительном радиусе
+* Радиус внутри объекта соответствует тому, что мы передали в конструктор
+* Подсчет периметра идет по верной формуле
+* Подсчет площади идет по верной формуле
+
+Исходный код:
+* [Абстрактный класс фигуры](https://github.com/qcha/ci-gradle-example/blob/main/src/main/java/ru/aarexer/figures/Figure.java)
+* [Класс круга](https://github.com/qcha/ci-gradle-example/blob/main/src/main/java/ru/aarexer/figures/Circle.java)
+* [Класс с тестами](https://github.com/qcha/ci-gradle-example/blob/main/src/test/java/ru/aarexer/figures/CircleTest.java)
+
+## Настройка репозитория
+После того, как проект был создан, нам нужно опубликовать его на Github. После публикации, находясь в нашем репозитории, мы увидим меню навигации, на котором красуется кнопка Actions.
+
+![Github Actions](../images/ci/github_actions_1.png)
+
+После нажатия на эту кнопку, перед вами появится следующее меню
+
+![Github Actions 2](../images/ci/github_actions_2.png)
+
+Поскольку наш проект сделан с системой сборки Gradle, выберем `Java with Gradle`, нажав Configure. После этого мы увидим окно редактирования файла с расширением `.yml`. В нем мы описываем необходимые действия, а также когда эти действия должны происходить.
+
+По умолчанию, пайплайн называется `Java CI with Gradle` (строка 8). Он запускается автоматически, когда какой-то коммит попадает в основную ветку или открывается пулл-реквест на основную ветку (строки 10-14).
+
+Далее описываются действия и где они выполняются (строка 14). Github предоставляет пользователям бесплатные раннеры, в этом шаблоне указывается `ubuntu-latest` (строки 15-16). Это значит, что задача будет выполнена на раннере гитхаба на операционной системе Linux Ubuntu последней версии. 
+
+После этого идут шаги, которые мы хотим выполнить. Во-первых, нам нужно установить JDK. По умолчанию указывается версия 11 и дистрибутив Temurin. После этого запускается задача build, выполняемая Gradle, которая производит полную сборку проекта.
+
+![Github Actions 3](../images/ci/github_actions_3.png)
+
+Немного поменяем то, что мы будем делать. Для начала, пусть данные действия выполняются только при коммите в основную ветку. Также, будем использовать JDK версии 17, в качестве дистрибутива возьмем Liberica. И, наконец-таки, мы будем не полностью собирать проект, а исполнять юнит-тесты, поменяем аргумент с `build` на `test`. 
+
+При этом, нужно понимать, что для исполнения юнит-тестов в Gradle выполняются следующие задачи:
+1) `compileJava`
+2) `processResources`
+3) `classes`
+4) `compileTestJava`
+5) `processTestResources`
+6) `testClasses`
+7) `test`
+
+Если вы желаете изменить то, что происходит в результате тестирования, то нужно описать собственную задачу в Gradle.
+
+![Github Actions 4](../images/ci/github_actions_4.png)
+
+Теперь нажмем кнопку `Commit changes...` и убедимся, что после того как произошел коммит в основную ветку наша задача выполнилась.
+
+![Github Actions 5](../images/ci/github_actions_5.png)
+
+## Итоги
+Настройка CI сегодня доступна каждому. Показанный пример можно совершенствовать. Например, после прохождения всех необходимых проверок создать докер образ приложения и отправить его в Docker Hub, откуда его может получить сервер и автоматически развернуть новую версию приложения.
+
+## Полезные ссылки
+
+1. [Официальная документация Github Actions](https://docs.github.com/ru/actions)
+2. [Проект, использованный в качестве примера](https://github.com/qcha/ci-gradle-example)
+

ci/intro.md

@@ -0,0 +1,34 @@
+# Continuous Integration (CI, Непрерывная интеграция)
+
+## Введение
+Непрерывная интеграция является ключевым аспектом современной разработки программного обеспечения. Она позволяет разработчикам интегрировать свой код регулярно и автоматически, что существенно улучшает качество и эффективность процесса разработки.
+
+## Зачем это нужно
+Когда речь заходит о разработке, особенно о работе в командах, требуется устанавливать правила и стандарты. Для того, чтобы все процессы были налажены, нужно постоянно проверять соответствие установленным стандартам. Помимо этого, у всего есть свои сроки. Тратить целый день на то, чтобы вручную доставить новую версию приложения на сервер - очень дорого.\
+\
+Например, можно использовать статический анализатор кода, который будет проверять форматирование кода по некоторым правилам. Затем, можно настроить сборку проекта, чтобы убедиться, что код в принципе компилируется. После этого, можно запустить юнит-тесты, а затем и интеграционные. Если хотя бы на одном из этапов что-то пойдет не так, то мы должны узнать, на каком конкретно и почему. Помимо того, что мы должны знать о проблемах, это не должно занимать большое количество нашего времени. Именно с этим помогает непрерывная интеграция.\
+\
+Таким образом, можно выделить несколько основных целей внедрения CI:
+
+1) Стандартизация процесса развертки
+    * Каждый раз выполняется один и тот же алгоритм, но с разными версиями программного обеспечения. В таком случае намного легче производить отладку процессов, на каком этапе и что пошло не так.
+2) Улучшение качества кода
+    * Непрерывная интеграция подразумевает под собой автоматизацию процессов - юнит-тестирования, интеграционного тестирования, статического анализа кода. Разработчики в таком случае больше работают над кодом, а DevOps задачи их касаются меньше.
+3) Свести количество ошибок к минимуму
+    * В случае возникновения проблем, разработчик быстро узнает об этом и сможет произвести откат на прошлую версию с помощью системы контроля версий, а затем устранить баг и интегрировать решение в реальном времени. Это также положительно влияет на скорость внедрения нового функционала.
+
+## Лучшие практики
+Везде есть свои лучшие практики. Непрерывная интеграция не стала исключением, поскольку данный процесс сегодня используется повсеместно.
+
+1) Автоматизация сборки
+    * Не нужно изобретать велосипед. Уже есть готовые решения для настройки CI. Используйте системы автоматической сборки, такие как Jenkins, Travis CI, GitLab CI или Github Actions, чтобы автоматизировать процесс сборки проекта при каждом изменении. \
+   [Подробнее о настройке CI в Github Actions](./github_ci.md).
+2) Автоматическое тестирование
+    * Настройте автоматическое тестирование, которое будет запускаться при каждой сборке. Включите юнит-тесты и интеграционные тесты для проверки работоспособности кода.
+3) Использовать контейнеры
+    * Используйте контейнерные технологии, такие как Docker и Kubernetes, для создания изолированных сред выполнения. Это даст гарантию, что ваше приложение будет работать одинаково в любом окружении.
+4) Использовать систему контроля версий
+    * Используйте систему контроля версий, такую как Git, для отслеживания изменений в коде и управления различными версиями. Это позволит вам легко восстановить предыдущие версии кода и отследить историю изменений.
+5) Непрерывная доставка (CD, Continuous Delivery)
+    * Рассмотрите возможность внедрения практики непрерывной доставки, которая позволит автоматически развертывать ваше решение в производственной среде после успешного прохождения всех тестов.
+