Скорее всего, вы пишете тесты для своего кода на Ruby. Существует множество форм тестирования, которые мы можем использовать, начиная с уровня изолированного модуля и заканчивая интеграцией в стек. Обычным рабочим процессом для этого является получение последней «чистой» фиксации базы кода, выполнение некоторых действий, а затем подготовка кода для объединения обратно в текущую ветвь разработки. Представив команду разработчиков в этом миксе, этот рабочий процесс будет усложняться. Вам приходится иметь дело с конфликтами слияний, иногда вам даже нужно будет поговорить с коллегами-разработчиками, чтобы разрешить изменения как на высоком, так и на низком уровне приложения.
Перед фиксацией вам нужно вытащить любые изменения в кодовой базе, объединить их и убедиться, что приложение соответствует всем зеленым показателям для набора тестов. Automated Continuous Integration (CI) обеспечивает важную помощь командам разработчиков, гарантирующую, что у них есть проверенная и правильная версия приложения.
Единственный разработчик
Небольшое предостережение — одинокий, изолированный и блаженно счастливый разработчик. Распространенной концепцией является то, что CI, будь это жизненно важно для команд, неприменимо к одиночному / внештатному разработчику. Я понимаю точку зрения, что если один разработчик несет полную ответственность за хранилище кода, и он / она запускает свой набор тестов перед каждым коммитом, то да, что еще может пойти не так?
Для меня этот набор тестов должен быть запущен в той же (точно) среде, в которой будет производственный код. Я считаю, что моя локальная машина разработки всегда менее всего применима. Кроме того, давай. Мы все люди, и несколько раз в прошлом у меня мог быть зеленый набор тестов, но я забыл зафиксировать добавленный файл или правильно настроить ресурс. CI избавляет нас от боли развертывания сломанного или неполного кода. Мы должны быть рабами ‘The Build’, если произойдут частые или даже просто надежные релизы.
Что там?
В Интернете есть много решений CI. Честно говоря, выберите имя и нажмите «-ci.org» в конце и посмотрите, что вы получите. Дженкинс и Хадсон, кажется, много крадут коммерческий центр внимания, и если вы работаете в мире Open Source, мне не нужно рассказывать вам о Трэвисе .
Для моей 9-5 работы мы используем Jenkins. Он гибкий и достаточно простой, чтобы начать работу, если вы хорошо разбираетесь в командной строке сервера. Для проекта с открытым исходным кодом (к моему стыду, у меня его нет, но я хочу его изменить), Travis полностью удовлетворит мои потребности, будучи размещенным и свободным для ОС. Но для личных / коммерческих проектов, что я использую?
Красные и синие лазеры
CiJoe — это легкое, простое и легко запускаемое CI-решение, независимо от ваших навыков администрирования сервера. Вы устанавливаете драгоценный камень, извлекаете репозитории и запускаете Джо.
Он не является специфичным для Ruby, но требует команды test командной строки, которая будет отвечать ненулевым значением в случае сбоя. Буквально за 5 минут у меня было 3 персональных проекта под CI. Это была огромная победа для меня, и я не был уверен, что получу такие результаты так же быстро, используя что-либо еще.
Ниже приведено пошаговое руководство для получения одинаковых результатов, независимо от того, являетесь ли вы единственным разработчиком или частью команды. Если у вас нет CI, и вам нравится идея получить стабильный рабочий процесс сборки / развертывания, тогда это для вас.
Гамбо строит мышцы! Хорошо, док?
Помимо того, что он большой фанат GiJoe (хотя он некоторое время назывался Action Force в Великобритании), CiJoe привлекает меня на многих других уровнях. Мне нравится легкий вес. Я использую rbenv над RVM , предпочитаю Vim RubyMine . Чтобы начать работать с CiJoe, все, что вам нужно, — это окно с Ruby. Нет необходимости устанавливать Java, Redis или что-либо еще. Таким образом, единственное требование — иметь удаленный сервер (желательно сконфигурированный как можно ближе к вашей производственной среде), который может запускать Ruby и Gems. В настоящее время я использую CiJoe на VPS с установленной Ubuntu, установленной Git и Ruby 1.9.3, созданной из исходного кода.
Проблема, прежде чем мы даже начнем
У меня возникла одна проблема при запуске сервера CiJoe. Это известная проблема, но она не была устранена в основной ветке. Это действительно позор, так как похоже, что проект больше не поддерживается. На момент написания, последний коммит был более года назад. Но патч, предоставленный Антоном Линдквистом , просто внедрить в свой собственный форк проекта, или вы можете даже просто использовать его форк .
Это делает камень немного сложнее в установке. Мы здесь не используем Gemfiles, поэтому определение URL Github вам не поможет. Время для какой-нибудь старой школы драгоценного камня. В основном, git clone git://github.com/mptre/cijoe.git гем на свой сервер, git clone git://github.com/mptre/cijoe.git . Перейдите в новый каталог cijoe и соберите gem, используя gem build cijoe.gemspec . Теперь, чтобы наконец установить гем, запустите sudo gem install cijoe.gem
Время идти (фурье)
В домашнем каталоге для моего пользователя я создаю папку с именем cijoe . Здесь я собираюсь создавать свои приложения для тестирования.
Вот и все, что нужно для настройки CiJoe в его основной форме. Но, конечно, нам нужно получить исходный код в эту папку. Не знаю как вы, но я пользуюсь GitHub. Github делает этот процесс действительно простой покупкой, позволяющей развертывать ключи в проектах. Если вы не уверены, как это сделать, все, что вам нужно сделать, это создать ключ ssh и добавить этот ключ в качестве ключа развертывания для проекта, который мы хотим использовать в CI.
Теперь это случай клонирования проекта в наш каталог cijoe в обычном режиме и запуска cijoe reponame . Это запускает приложение Sinatra, к которому мы можем получить доступ, перейдя по server_ip:4567 и проверив выходные данные теста или действительно запустив другую сборку.
Делаем CI более управляемым
Теперь CI должен сделать нашу жизнь проще. Идея фиксации изменений, входа на сервер CI, получения последних изменений, повторного запуска CiJoe, перехода на страницу CiJoe и нажатия кнопки «Построить» — полный кошмар. Как вы уже догадались, так не должно быть.
Прежде всего, навигация по IP-адресу неэффективна. Поэтому добавьте запись DNS, которая указывает на ci.yourdomain.tld .
Я использую Apache для обслуживания своих доменов, поэтому мне нужен «сайт», который отвечает на новый домен. Это то же самое, что создание любого домена на вашем сервере. Вы можете увидеть пример того, что я использую в этой сути . Я настроил базовую аутентификацию для корня этого домена. Тем не менее, это не будет использоваться здесь, и вы поймете, почему через минуту.
Как я упоминал ранее, CiJoe использует Sinatra в качестве внешнего интерфейса. Это означает, что добавление базовой аутентификации в конфигурации apache не поможет. Мы будем обращаться к CI на ci.example.com:<port_number> .
Конфигурация сборки через Git
CiJoe использует конфигурацию git для изменения поведения сборки. Одним из этих вариантов является использование базовой аутентификации. В вашем локальном хранилище настройте этот конфиг, используя
git config --add cijoe.user username git config --add cijoe.pass secret_password
Теперь, когда мы перейдем к CI-серверу, нам будет предложено ввести имя пользователя и пароль. Да, это бесполезно (и опасно), если проект общедоступен на Github, но нас здесь интересуют только частные проекты.
Сборка проекта также осуществляется через настройки конфигурации git. Здесь мы определяем настройку и запускаем нашу тестовую среду. Это однострочная сделка, поэтому вам придется использовать && для объединения исполняемых шагов.
git config --add cijoe.runner "bundle install && bundle exec rake db:drop db:create db:migrate && bundle exec rake spec"
Или, что еще лучше, создайте грабли, объединяющие много. Я использую задачу ci для этой цели.
desc "Setup the CI env" task :ci do Rake::Task['db:drop'].invoke Rake::Task['db:create'].invoke Rake::Task['db:migrate'].invoke Rake::Task['db:test:prepare'].invoke Rake::Task['spec'].invoke end
После этого наша предыдущая настройка конфигурации преобразуется в:
git config --add cijoe.runner "bundle install && bundle exec rake ci"
Смотря это становится зеленым
Со всем этим мы можем начать сборку. В командной строке сервера перейдите туда, где были клонированы проекты, и запустите cijoe <project_name> . Если вы посмотрите на ci.example.com:4567 , вы увидите интерфейс CiJoe, и при нажатии кнопки «Build» начнется сборка, и результаты будут отображены.
Как мы говорили раньше, все это не кажется автоматизированным. Один из хорошо известных грязных секретов CiJoe заключается в том, что он начнет сборку при получении запроса на публикацию, и Github знает, как это сделать. Но сначала нам нужно запустить сервер CiJoe в фоновом режиме. Просто используя nohup мы можем приступить к работе и определить порт, на котором работает сервер CI.
nohup cijoe -p 4000 <your_repo> &
Стоит отметить, что CiJoe будет запускать только одну сборку за раз, если очередь сборок не включена. Опять же, это git config, определенный как git config --add cijoe.buildqueue true . Это определенно подходит для команд или индивидуальных разработчиков с множественными изменениями за короткий промежуток времени или, наоборот, со значительной задержкой сборки.
В административном интерфейсе Github в разделе «Service Hooks» добавьте «URL-адрес Webhook» к домену, на котором работает CI-сервер, в данном случае с аутентификацией, которая будет http://username:[email protected]:4000 . Нажатие кнопки тестирования для этого хука вызовет сборку CI. Хотите больше проектов под CI? Это просто случай клонирования проекта и повторного запуска nohup .
nohup cijoe -p 4001 <your_other_repo> &
Будучи убеждена?
Перечитывая статью, мне пришлось немного переосмыслить закрытие. Описание всех настроек и детализация исправления для начальных проблем звучит, ну, больно. Но я уверяю вас, что это не так. Лично, это было буквально 5 минут, включая поиск ошибок, установку разветвленного драгоценного камня и запуск основного сервера CI. Настройка дополнительных доменов, веб-хуков и уведомлений занимает немного больше времени.
Однако вы должны сравнить это с настройкой Дженкинса или Хадсона и всех его зависимостей. Оставляя все это в стороне, CiJoe является отличным инструментом в цепочке предоставления выпускаемого программного обеспечения в регулярном темпе.
Немного обидно, что проект, кажется, больше не поддерживается, это небольшой проект, который для меня делает CI действительно доступным для небольших команд и одиночек. Может быть, каталог с открытым исходным кодом на моей коробке разработчика увидит, что CiJoe снова найдет себя. CiJane кто-нибудь?