Советы по непрерывной интеграции?

Question

Я работаю над настройкой сервера непрерывной интеграции (используя Integrity) для моего приложения на Rails, и мне нужен совет:

• Большинство людей настраивают CI для создания и тестирования своего приложения при каждом отправке в центральный репозиторий SCM или только при переносе в промежуточную ветвь?
• Я буду использовать CI-сервер для автоматического запуска flay, flog, reek и rcov - есть ли другие инструменты тестирования или покрытия кода, которые мне следует запустить?
• Я планирую развернуть свое приложение на Slicehost. Должен ли я настроить сервер CI на отдельном слайсе Slicehost, который должен быть идентичен (с установленными гемами, библиотеками и т. Д.) Моему производственному слайсу?
• Если я делаю использование отдельного слайса для CI, есть ли какой-либо вред в использовании слайса CI и для промежуточного сервера?

С уважением,

Jacob

Answer 1

Большинство людей настраивают CI для создания и тестировать их приложение при каждом нажатии на их центральный репозиторий SCM, или только когда подталкивать к своей постановочной ветви?

Зависит от размера команды и скорости проекта. Чем больше людей работает над разными ветвями кода, тем чаще и энергичнее я хочу, чтобы CI запускался. Я бы порекомендовал вам начинать с максимально возможного количества КИ и постепенно отступать от него по своему усмотрению.

Я буду использовать CI-сервер для автоматически запускать flay, flog, reek, и rcov - есть ли другие инструменты тестирования или покрытия кода I должен бежать?

Все, что покрыто метрической фу, - хорошее начало. Если в вашей команде есть технический писатель и / или документация является частью вашей поставки, вы также можете добавить туда rdoc.

Я планирую развернуть свое приложение на Slicehost. Должен ли я настроить CI сервер на отдельном слайсе Slicehost это установлено, чтобы быть идентичными (WRT установленные драгоценные камни, библиотеки и т. д.) к моему производственный срез?

Если вы можете себе это позволить, да. Обычно небольшие команды и новые стартапы не могут позволить себе выделенный сервер для каждой задачи, но я большой сторонник изоляции. Что касается идентичной установки, продавайте все, что вы можете; установка нового сервера должна быть быстрой, простой и автоматизированной.

Если я использую отдельный срез для CI, есть ли вред в использовании CI срез для промежуточного сервера?

Единственный вред - перекрестное загрязнение между общими ресурсами, например, Версии гемов, ресурсы баз данных и т. д. Если вы методичны, у вас, вероятно, все будет в порядке, но если вы можете позволить себе отдельные серверы для каждой среды, я бы предпочел безопасность, а не сожаление.

Answer 2

Мы используем Rackspace для развертывания и тестирования. Для разработки у нас есть три среза, расположенных следующим образом:

Dev

Размещает ртутный репозиторий, который постоянно обновляется разработчиками (обычно это просто слияние их ветви с основной веткой). Тесты проводятся не при регистрации, а по расписанию. На этом сервере установлена ​​MySQL с тестовой базой данных.

Test

Размещает ртутный репозиторий, обновляемый только менеджером разработки. Используется для приемочных испытаний, но также имеет ночные тестовые прогоны. На этом сервере установлена ​​MyDQL с тестовой базой данных.

Deploy

После успешного QA мы отправляем обновления с Test на сервер Deploy. Этот сервер можно считать «setup.exe» - клиентские срезы должны плавно инициализироваться из резервной копии этого среза. Тестирование на этом срезе действительно сводится к тому, чтобы это могло произойти.

Новая настройка клиента

Rackspace позволяет вам копировать сервер, чтобы мы могли вернуться к нескольким воплощениям системы.

Когда нужно настроить нового клиента, мы инициализируем его новый срез из последней версии Deploy, добавляем сертификат для HTTPS и регистрируем новый срез в DNS.

Мы также храним такие вещи, как /etc/nginx/nginx.conf и / etc / mongrel_cluster под контролем версий.

Chris

Answer 3

Я рекомендую вам прочитать это .

Answer 4

Если у вас более формальный процесс выпуска и отдельная команда тестирования, которая не может тестировать так быстро, как регистрируются разработчики, вы можете настроить две сборки. (1) Один очень быстрый и легкий процесс без постоянных артефактов или хранилища, где каждая сборка перезаписывает предыдущую после завершения. Это постоянно работает против каждой интеграции, чтобы сказать разработчикам, что только что сломалось. Эти сборки только для внутреннего использования не контролируются менеджерами выпусков, кроме как решить, когда будет подходящее время для типа сборки (2), который является менее частой сборкой, которая запускает все тесты (включая ручные), создает полные артефакты и сохраняет метаданные пронумеровать и воспроизвести сборку.

Answer 5

Инструменты тестирования и покрытия кода - вы хотите включить в свой пакет столько из них, сколько имеет смысл, не прерывая циклы сборки. например если вы добавите слишком много, а время сборки превысит несколько минут, продолжать сборку после каждого коммита будет неэффективно.

Сборка после каждого коммита, IMO, как для вашего центрального, так и для промежуточного местоположения. Вы можете получить двойное покрытие здесь, но если у вас есть пропускная способность и процессор, почему бы и нет?

Я согласен с использованием установки с двумя срезами, и да, одна из причин заключается в том, что она позволяет использовать второй срез в качестве промежуточной / конечной области тестирования. Кроме того, если вы развернете свой промежуточный срез на рабочий срез, вы сможете использовать преимущества своей локальной сети при передаче информации между срезами. Так гораздо быстрее.

Надеюсь, это поможет: -)

Answer 6

Похоже, вы можете использовать сервер CI для двух целей:

1) Непрерывная интеграция - это, вероятно, подтолкнет к центральной части репо SCM. Используйте инструмент CI, чтобы убедиться, что область, в которой разработчики интегрируют свою работу, функционирует. Это обеспечит быструю обратную связь с командой разработчиков. Вы должны выполнить столько тестов, сколько сможете сделать здесь очень быстро.

2) Управление сборкой. В отличие от вашей промежуточной ветки, сборки, вероятно, сделаны, чтобы их можно было более тщательно тестировать и контролировать для дальнейшего развертывания. Здесь я бы запустил все тесты, которые вы настроили (и другие авторы предлагают), и, вероятно, внимательно следил за этими сборками.

Если это так, я определенно собрал бы обе ветви, но ваша коллекция тестов и то, как вы поддерживаете результаты сборки для каждой ветви, могут отличаться. Опять же, если вы в состоянии поддерживать чистоту своей магистрали, что дает вам отдельная промежуточная ветвь?