Непрерывный совет интеграции?
Я использую блок link_to do-end, поэтому вышеупомянутые предыдущие решения не работали для меня.
Если вы хотите встроить другие теги в свой тег, вы можете использовать блок link_to do-end.
<%= link_to favourite_companies_path(:company_id => @company.id, :another_url_param_here => "bar"), { :class => "ui-button-text button_text", :title=> "We can have more html attributes as well" } do %>
<i class="fa fa-star"></i>
<%= @company.company_name %>
<% end %>
В данном случае это
<%= link_to path(url_params), html_options = {} do %>
<% end %>
6 ответов
Если у вас более формальный процесс выпуска и отдельная группа тестирования, которая не может тестировать так быстро, как проверяют разработчики, вы можете настроить две сборки. (1) Один очень быстрый и легкий процесс без постоянных артефактов или хранилища, при котором каждая сборка перезаписывает предыдущую после завершения. Это постоянно работает с каждой интеграцией, чтобы сообщить разработчикам, что только что сломалось. Эти сборки, предназначенные только для внутреннего использования, не контролируются менеджерами выпусков, кроме решения, когда будет подходящее время для типа сборки (2), который является менее частой сборкой, которая запускает все тесты (включая ручные), создает полные артефакты и сохраняет метаданные. пронумеровать и воспроизвести сборку.
Похоже, Возможно, вы захотите использовать CI-сервер для двух целей:
1) Непрерывная интеграция - это, вероятно, будет толчком к центральной части репозитория SCM. Используйте свой инструмент CI, чтобы убедиться, что область, в которой разработчики объединяют свою работу, работает. Это обеспечит быструю обратную связь с командой разработчиков. Вы должны выполнить столько тестирования, сколько сможете сделать здесь очень быстро.
2) Управление сборкой - для вашей промежуточной ветки, сборки, вероятно, сделаны, чтобы их можно было более тщательно тестировать и управлять ими для дальнейшего развертывания. Здесь я бы провёл все тесты, которые у вас есть (и другие предложения), и, вероятно, внимательно отслеживал бы эти сборки.
Если это верно, я бы определенно построил обе ветки, но ваш набор тестов и то, как вы поддерживаете свои результаты сборки для каждой ветки, могут быть разными. Опять же, если вы можете поддерживать свою основную ветку в чистоте, что дает вам отдельная промежуточная ветвь?
но ваша коллекция тестов и то, как вы поддерживаете результаты сборки для каждой ветки, могут отличаться. Опять же, если вы можете поддерживать свою основную ветку в чистоте, что дает вам отдельная промежуточная ветвь? но ваша коллекция тестов и то, как вы поддерживаете результаты сборки для каждой ветки, могут отличаться. Опять же, если вы можете поддерживать свою основную ветку в чистоте, что дает вам отдельная промежуточная ветвь?Мы используем Rackspace для развертывания и тестирования. Для разработки у нас есть три части, расположенные следующим образом:
Dev
Размещает ртутный репозиторий, постоянно обновляемый разработчиками (обычно просто объединяя свою ветку с основной веткой). Тесты запускаются не при регистрации, а по расписанию. На этом сервере установлена MySQL с тестовой базой данных.
Test
Размещает ртутный репозиторий, обновляемый только менеджером разработчиков. Используется для приемочного тестирования, но также имеет ночные тесты. На этом сервере установлен MyDQL с тестовой базой данных.
Развертывание
После успешного контроля качества мы отправляем обновления с тестового на сервер развертывания. Этот сервер можно рассматривать как «setup.exe» - клиентские фрагменты должны плавно инициализироваться из резервной копии этого фрагмента.
Инструменты тестирования и покрытия кода - вы хотите включить в свой набор столько из них, сколько имеет смысл, не прерывая ваши циклы сборки. например, если вы добавляете слишком много, а время сборки превышает несколько минут, то продолжать сборку после каждой фиксации будет неэффективно.
Сборка после каждой фиксации, IMO, как для центрального, так и для промежуточного местоположения. Здесь вы можете получить двойное покрытие, но если у вас есть пропускная способность и ЦП, почему бы и нет?
Я согласен с использованием настройки с двумя срезами, и да, одна из причин заключается в том, что она позволяет вам использовать второй срез в качестве промежуточной / финальной области тестирования. Кроме того, если вы выполняете развертывание из промежуточного слоя в производственный, вы можете использовать преимущества их локальной сети при передаче информации между слайсами. Так сделать намного быстрее.
Большинство людей настраивают CI для сборки и тестировать свое приложение при каждом нажатии на центральный репозиторий SCM, или только когда отправка в промежуточную ветвь?
Зависит от размера команды и скорости проекта. Чем больше у меня людей работает над различными ветвями кода, тем чаще и энергичнее я хочу, чтобы CI запускался. Я бы порекомендовал вам начать с максимально возможного количества CI и постепенно отказываться от него, если сочтете нужным.
Я буду использовать сервер CI для автоматически запускать flay, flog, reek, и rcov - есть ли другие инструменты тестирования или покрытия кода I должен бежать?
Все, что покрывается метрикой-фу, - хорошее начало. Если в вашей команде есть технический писатель и / или документация является частью вашей поставки, вы также можете добавить туда rdoc.
Я планирую развернуть свое приложение на Slicehost. Стоит ли настраивать CI сервер на отдельном слайсе Slicehost это настроено, чтобы быть идентичным (wrt установленные гемы, библиотеки и т. д.) на мой производственный кусок?
Если вы можете себе это позволить, то да. Обычно небольшие команды и новые стартапы не могут позволить себе иметь выделенный сервер для каждой задачи, но я - большой сторонник изоляции. Что касается идентичной настройки, продавайте все, что вы можете; настройка нового сервера должна быть быстрой, простой и автоматизированной.
Если я использую отдельный фрагмент для CI, есть ли вред в использовании CI slice для промежуточного сервера?
Единственный вред - это перекрестное заражение между общими ресурсами, например версиями гемов, ресурсами базы данных и т. д. Если вы будете методичны, вы, вероятно, будете в порядке, но если вы можете позволить себе отдельные серверы в зависимости от окружающей среды я бы предпочел лучше обезопасить, чем сожалеть.