Вот так неожиданно для себя узнал что Selenium Webdriver работает без Java. До этого всегда был уверен, что такого не может быть. Возможно, это произошло с релизом Selenium 2, возможно нет. Но мой мир уже не будет таким как прежде. 

Не поверил, пока сам не убедился в этом. Пришлось ставить виртуалку без Java и проверять следующий код:


Build succeeded, 156 warnings

Published 11/18/2013 by e0ne in Offtopic

Запустил “make build” и получил 156 ворнингов:(... Хотя, достаточно быстро получил более радужное число - 69, что тоже не мало. Нужно фиксить дальше, а пока - немного очень IMHO на эту тему.

Отключать или нет параметр “mark warnings as errors” (название может отличаться, но суть остается той же) - часто решают для конкретного проекта и/или команды. Иногда это не мешает работы продукта. Я бы сказал что в 98% случаев это не мешает, зато остаются 2%. И баги, попавшие в те самые 2%, часто являются самыми трудновоспроизводимимы и затратными по времени на исправления.

Итак, из-за чего появляются warnings? Самые частиы причины - это:

  • использование deprecated и/или недокументированного API.
  • несоответствие кода гайдлайнам (guidelines) и/или принятым стандартам языка программирования, фреймворка и т.д.
  • проблемы с настройкой окружения (environment).

Что плохого в использовании deprecated API? Ничего, если приложение будет удалено не посже, чем сразу после перговго запуска. В противном случае, рано или поздно, после очередного обновления используемой платформы и/или фреймворка что-то перестанет работать, т.к. deprecated код будет удален. Таким образом, ваш код, который использует устаревший API фреймворка, автоматически становится deprecated :). Готовы ли вы писать заведомо legacy код?

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

Код, который не соответствует стандартным гайдлайнам, как минимум, - странный. IMHO. Нет, я понимаю, что при использовании StyleCop (для C#) практически невозможно писать код, соответствующий всем его требованиям, но для того же Python’а, держать код в соответствии с PEP-8 достаточно просто. Трудности бывают только с 80-ю символами в строке. С PyLint все немного сложнее. Но никто не заставляет выполнять все требования. Главное - здравый смысл и правильная настройка инструментов, которые используются.

Проблемы с настройкой окружения. Тут не буду много писать, т.к. эта тема тянет на отдельный пост в блоге, который уже давно хочется написать. Скажу только то, что один и тот же код (id коммита, tag, и т.д.) должен, по возможности, собираться одинаково на всех используемых окружениях. Это, как правило, рабочий ПК разработчиков и тестировщиков и билд-серверы. Иначе где-то что-то пойдет не так.

Не попал в мой классификацию еще один случай - содержимое stderr. Бывает, что только туда пишуться какие-либо предупреждения, которые остаются непрочитанными. Давно уже руки тянуться помечать все билды как failed, если что-то есть в stderr, но пока это сделать не получается, т.к. “хороший продукт !== работающий и/или безбажный продукт”, а “хороший продукт == радующий пользователя/заказчика продукт”. Как-то так.



Разберем ситуацию, ставшую достаточно распространенной в наше время. Есть распределенная команда, допустим в двух городах (А и Б), которая работает над одним крупным проектом. Сборка проекта происходит на Jenkins’е в городе А и длится, например 3 минут. Скачать готовый продукт из города А в город Б можно в среднем за 30 минут (в зависимости от времени суток, загрузки канала, фазы луны и т.д.). Итого: команде из города Б нужно ждать час(60 минут) чтобы запустить/протестировать свежий билд. Очевидно, это достаточно много. Нужно ускорять.

Рассматривать вопросы вынесения этого всего (CI) в облако и прочее я не буду по двум причинам:

 

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

 

Также я пропущу вопросы синхронизации репозиториев с исходниками и прочие инфраструктурные вещи, не относящиеся к данной теме.

Решать данную проблему буду так: в обоих офисах настраивается Jenkins-нода, на которой можно собирать свежий билд. Главная задача - 2 одновременных билда одного проекта в разных офисах.

Делается это, примерно, так:

 

  1. Заходим на наш Jenkins и устанавливаем нужные плагины (Jenkins => Manage Jenkins =>  Manage Plugins => Available). Нам нужен “Throttle Concurrent Builds Plugin” (https://wiki.jenkins-ci.org/display/JENKINS/Throttle+Concurrent+Builds+Plugin) и NodeLabel Parameter Plugin (https://wiki.jenkins-ci.org/display/JENKINS/NodeLabel+Parameter+Plugin).
  2. Настраиваем Slave node. Документация лежит тут: https://wiki.jenkins-ci.org/display/JENKINS/Step+by+step+guide+to+set+up+master+and+slave+machines.
  3. Настраиваем нашу Job’у для параллельного выполнения на двух нодах. Я для примера создал Fake-long-job, которая выполняет простой bash-скрипт “sleep 20;”.
    • Отмечаем флаг “This build is parameterized”
    • Добавляем параметр Node

    • Выбираем на каких нодах можно выполнять билд

    • Настраиваем одновременные билды. В моем случае их может быть 2, по одному на каждой ноде

      .
    • Нажимаем кнопку Save.
  4. Проверяем, что все работает, запустив два билда на разных нодах.

 

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