Как мы делаем выпуски с участием нескольких платформ с использованием Jenkins?

У нас немного запутанная ситуация на нашей сборочной машине ...

Мне, наконец, удалось заставить работать одну матричную сборку, тип задачи «сначала проверить, что все компилируется», который просто компилирует все на текущей платформе, на которой она запущена. Он отлично работает на нескольких платформах (единственная проблема, которую он может иметь, заключается в том, что он многократно компилирует Java-код, хотя его, вероятно, можно было бы оптимизировать для этого один раз).

Я полагаю, что настроить матричную сборку для «установщиков сборки» тоже не составит большого труда.

Но есть две проблемы, которые обязательно коснутся.

  1. Мы распространяем один zip-файл, который в идеале содержал бы все зависящие от платформы двоичные файлы в одном zip-файле, чтобы уменьшить дублирование (по сути, это библиотека, которую мы раздаем другим).

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

Мы используем Archive for Clone Workspace SCM в качестве этапа после сборки для этой начальной сборки матрицы, но похоже, что это выполняется независимо в каждой ОС, и не предпринимается никаких попыток объединить результаты вместе.

Как другие люди решают все эти проблемы?

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

Варианты, которые включают альтернативы Jenkins, также будут серьезно рассмотрены, так как в последнее время ... количество проблем, с которыми мы сталкиваемся, огромно.


person Trejkaz    schedule 20.11.2013    source источник


Ответы (1)


Вот что мы в итоге установили и что работает:

  • Проект «Платформа-релизы» по-прежнему остается «Matrix Build».
  • Каждое подчиненное устройство помечено соответствующей платформой, и мы используем метку подчиненного устройства в качестве параметров матрицы.
  • «Архивные артефакты» используются для архивирования полезных файлов. («Clone Workspace SCM» кажется тупиком при работе со сборками матриц.)
  • Проект unified-Release - это обычная сборка, которая копирует артефакты из платформенных релизов. Поскольку мы копируем артефакты без указания конкретной платформы, мы получаем артефакты для всех платформ, которые появляются в каталогах с именами /os/windows, /os/macosx и т. Д.
  • Сборка Ant знает о местонахождении артефактов (они находятся вне рабочей копии) и перед загрузкой помещает все файлы в единую структуру каталогов.
  • Плагин "Parameterized Trigger" настроен для релизов платформы, чтобы запускать унифицированные релизы, чтобы версия svn, с которой он работает, соответствовала фактическим созданным файлам. К сожалению, нам приходится проверять весь репозиторий, несмотря на то, что мы используем только крошечную его часть, потому что есть ошибка (предположительно в подключаемом модуле Subversion), которая в противном случае не позволяет проверять подкаталоги с правильной ревизией.
person Trejkaz    schedule 07.02.2014