The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Rultor - это помощник команды разработчиков. Travis - это система непрерывной интеграции с хостингом. В этой статье я покажу, как наши проекты с открытым исходным кодом используют их совместно для достижения беспрерывной доставки.
Я покажу несколько практических сценариев.
jcabi-mysql-maven-plugin - это плагин Maven для интеграционного тестирования MySQL. @ChristianRedl представил запрос на слияние #35 с новой функцией. Я проверил запрос и попросил Rultor объединить его с master:
Как вы видите, Rultor выполнил фактическую операцию слияния. Я предоставил ему доступ к проекту, добавив его учетную запись GitHub в список совладельцев проекта.
Прежде чем дать “зеленый свет” Rultor, я проверил состояние предварительной сборки, сообщенное Travis:
Travis обнаружил новый коммит в запросе на слияние и немедленно (без моего участия) запустил сборку в этой ветке. Сборка прошла успешно, поэтому Travis показал мне зеленый знак. Я посмотрел на этот знак и на код. Поскольку все проблемы в коде были исправлены автором запроса на слияние и Travis не выдавал ошибок, я дал “зеленый свет” Rultor.
Несмотря на то, что предыдущий шаг гарантирует, что ветка master всегда чиста и стабильна, мы используем Travis для ее непрерывной интеграции. Каждый коммит, сделанный в master, запускает новую сборку в Travis. Результат сборки изменяет статус проекта в Travis: либо “ошибка”, либо “прошла успешно”.
jcabi-aspects - это набор аспектов AOP AspectJ. Мы настроили Travis для его непрерывной сборки. Вот значок, который он создает (левый):
Еще раз, позвольте мне подчеркнуть, что, хотя только для чтения master является надежной защитой от поломанных сборок, это не гарантирует, что в любой момент master будет стабильным. Например, иногда модульные тесты иногда неожиданно завершаются с ошибкой из-за изменений в календаре, в среде, в зависимостях, в качестве сетевого соединения и т.д.
Что касается идеала, модульные тесты должны либо завершаться с ошибкой, либо проходить, потому что они не зависят от среды. Однако, на практике модульные тесты далеки от идеала.
Вот почему комбинация только для чтения master с Rultor и непрерывной интеграцией с Travis дает нам большую стабильность.
jekyll-github-deploy - это Ruby-дополнение, автоматизирующее развертывание сайтов Jekyll на GitHub Pages. @leucos отправил запрос на объединение #4 с новой функцией. Запрос успешно объединен в основную ветку master.
Затем Rultor был поручено мной выпустить ветку master на RubyGems и установить новую версию 1.5:
Rultor выполнил простой скрипт, предварительно настроенный в его .rultor.yml:
Скрипт параметризован, как вы видите. В скрипт передается один параметр, ${tag}, который был предоставлен мной в GitHub issue, когда я отправил команду в Rultor.
Скрипт тестирует работу гема (интеграционное тестирование) и после этого производит очистку.
Затем оно изменяет версию самого себя в jgd.gemspec на ту, которая указана в ${tag} (это переменная окружения), и создает новый файл .gem.
Наконец, он загружает новый файл .gem на RubyGems, используя учетные данные для входа из ../rubygems.yml. Этот файл создается Rultor прямо перед запуском скрипта (этот механизм обсуждается ниже).
Если все работает нормально и RubyGems подтверждает успешное развертывание, Rultor отправляет отчет в GitHub. Точно так и произошло в pull request #4.
s3auth.com - это шлюз базовой HTTP-аутентификации для ведер Amazon S3. Это веб-приложение на Java. В пул-запросе #195 была исправлена проблема с утечкой ресурсов @carlosmiranda, и пул-запрос был объединен Rultorом.
Затем @davvd поручил Rultor’у развернуть ветку master в рабочей среде. Rultor создал новый контейнер Docker и запустил mvn clean deploy в нем.
Maven развернул приложение в CloudBees:
Вся процедура заняла 21 минуту, как видно из отчета, сгенерированного Rultorом.
Есть один важный трюк, который стоит упомянуть. Развертывание в рабочую среду всегда означает использование безопасных учетных данных, таких как логин, пароль, SSH-ключи и т.д.
В этом конкретном примере плагину Maven CloudBees требуется ключ API, секрет и имя веб-приложения. Эти три параметра хранятся в безопасности и не могут быть раскрыты в “открытом исходном коде” способом.
Таким образом, есть механизм, который настраивает Rultor соответствующим образом через его файл .rultor.yml (обратите внимание на несколько первых строк):
Эти записи YAML информируют Rultor, что ему нужно получить файл assets/s3auth/settings.xml из закрытого репозитория yegor256/home на GitHub и поместить его в рабочий каталог контейнера Docker, сразу перед запуском сборки Maven.
Этот файл settings.xml содержит секретные данные, необходимые плагину CloudBees для развертывания приложения.
Как развернуть на CloudBees одним щелчком мыши объясняет этот процесс еще лучше.
И Rultor, и Travis являются бесплатными хостинговыми продуктами, предоставляемыми при условии, что ваши проекты являются открытыми и размещены на GitHub.
Другие хорошие примеры использования Rultor+Travis можно найти в следующих проблемах GitHub: jcabi/jcabi-http#47, jcabi/jcabi-http#48
PS. Вы можете сделать что-то подобное с AppVeyor для платформы Windows: Как AppVeyor помогает мне проверять запросы на получение перед тем, как Rultor объединяет их.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-17 at 14:34
