Привет, дорогой читатель!

Наверняка в жизни каждого из нас есть вещи, про которые стыдно вспомнить, не то, что рассказать. И всё же я вынужден признаться: до недавнего времени coding-interview репозиторий не использовал возможности непрерывной интеграции. “Какой позор!” - прокричат одни. “Да кому она вообще нужна?!” - возразят другие.

Со своей стороны я предлагаю вместе разобраться, зачем же разработчики всё чаще используют современные инструменты непрерывной интеграции, а не зажигают огонь трением двух палочек, и на примере GitHub Actions добавить возможность непрерывной интеграции в coding-interview репозиторий.

Так что же из себя представляет непрерывная интеграция?

Непрерывная интеграция (continuous integration, CI) - это подход, который подразумевает под собой внесение частых изменений в общую кодовую базу, для максимально быстрого выявления ошибок, которые возникают в том числе в процессе интеграции.

“А где же тесты?” - спросит внимательный читатель. Ну раз спросит, то почему бы не ответить? Тесты являются лишь одной из возможностей обнаружения ошибок при частом внесении изменений, делая сам процесс непрерывной интеграции ещё более надёжным. Поэтому де-факто тесты являются частью самого процесса непрерывной интеграции.

На сегодняшний день существует огромное количество инструментов, которые упрощают процесс непрерывной интеграции: Jenkins, Travis, Teamcity, GitLab CI/CD, GitHub Actions и многие другие. Так как наш репозиторий расположен на GitHub, то продолжим знакомство на примере его инструментов, хотя сама по себе идея везде одинаковая:

1. Определить события, которые будут вызывать те или иные задания при внесении изменений в общую кодовую базу;
2. Для каждого задания определить набор действий (шагов), которые должны быть выполнены в контексте этого задания.

GitHub Actions настраиваются с помощью конфигурационного файла в формате YAML, который должен быть расположен в директории .github/workflows/. Ниже приведём пример конфигурационного файла:

В целом сами по себе конфигурации достаточно информативные, но всё же дадим некоторые пояснения:

• on: [ push ] определяет список событий, по которым должен активироваться данный процесс. Условия возникновения событий при этом могут быть уточнены, например названиями веток, на которых данное событие должно вызываться или не вызываться;
• jobs описывает список заданий, которые должны быть выполнены в контексте данного процесса. В нашем случае мы создали только задание test;
• runs-on: ubuntu-latest определяет тип машины, на которой должен быть запущен данный процесс;
• steps определяет список действий (шагов), которые необходимо выполнить:
  • actions/checkout@v2 выполняет клонирование исходного кода на сервер выполнения;
  • actions/setup-dotnet@v1 настраивает окружение dotnet;
  • dotnet build cs-solvers --configuration Release выполняет сборку проекта;
  • dotnet test cs-solvers запускает тесты.

Чтобы посмотреть результат работы процесса, необходимо выбрать вкладку Actions внутри репозитория:

И выбрать интересующий нас процесс:

Осталось добавить в корневой README.md файл ссылку на результат работы нашего процесса в формате:

То есть следующую строку:

В итоге получим значок статуса в описании проекта.

Теперь выглядит всё по-взрослому! Поэтому можно начинать прощаться. Всем хорошего настроения и стабильных сборок!