Рекомендации по непрерывной сборке инфраструктуры в первую очередь для C ++; Целостность GreenHills

Question

Мне нужны ваши рекомендации по продуктам непрерывной сборки для большого (1-2MLOC) проекта разработки программного обеспечения. Характеристики:

• Контроль версий ClearCase
• Приблизительно 80% C ++; 15% Java; 5% сценарий или низкий уровень
• Компиляции для ОС Green Hills Integrity, а также некоторых окон и блоков JVM
• В основном встроенная система; также включает некоторые элементы пользовательского интерфейса и поддержку разработки (инструменты моделирования, инструменты настройки и т. д.)
• Каждая условная «версия» поставляемого продукта включает в себя образы развертывания для ряда плат, компьютеров с пользовательским интерфейсом и т. Д. (~ 10 отдельных образов; 5 различных операционных систем)
• Необходимость поддерживать / отслеживать множество одновременных версий, которые, в частности, созданы для различных пакетов поддержки плат
• Время цикла сборки является серьезной проблемой в проекте, ему нужна поддержка для любых функций, помогающих решить эту проблему (я думаю, в основном нужно управлять большой фермой машин сборки).
• Работает в защищенной среде (это правительственная программа) ( Отредактировано для добавления : Это секретная программа; аутсорсинг инфраструктуры сборки не требует участия.)

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

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

(отредактировано по адресу @ комментарий Дэна.; -)

Answer 1

Исходя из моего опыта работы с подобными системами, эта проблема состоит примерно из двух частей:

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

• Способ вызова этих командных строк на различных серверах в ферме сборки.

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

Для первых у нас есть доморощенное решение, которое начиналось как простой сценарий оболочки bash и росло ... довольно существенно. Исходя из опыта, я бы посоветовал начать с python, а не с bash - вы потратите гораздо больше кода на обработку установки и настройки, чем на фактический вызов программ. (Кроме того, возможно, вам будет проще запустить его в Windows, если вы это делаете.)

Вещи, которые я обнаружил, являются ключевыми в полезности нашего скрипта:

• Повторяемость в железной оболочке. У нас есть стандартный набор инструментов для сборки, и сценарии начинаются с очистки переменных среды. Есть очень мало параметров командной строки; все идет в конфигурационные файлы, а те в контроле версий.

• Logging. Мы создаем журнал каждой команды, выполняемой сценарием сборки.

• Наследование файла конфигурации. Каждый вариант нашего программного обеспечения получает файл конфигурации, и эти файлы могут содержать более общие параметры (которые включают даже более общие параметры).

• расширяемость. Когда мы добавляем новый исходный компонент, довольно просто добавить набор инструкций для сборки этого компонента (и инструкции могут быть произвольным кодом bash). Часть «может быть произвольным кодом», вероятно, является ключевой здесь; Ни в коем случае ранее существовавший продукт не сможет выполнять все изворотливые вещи, которые вам нужны для большой сложной реальной системы.

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

Answer 2

Когда я вижу акцент на масштабируемости и безопасности в системе сборки, я начинаю думать, что вы можете быть кандидатом на системы построения корпоративного класса / системы КИ. Удобно, что вы тоже можете себе это позволить. Годовая статья SD Times содержит базовую разбивку между инструментами сборки на уровне предприятия и команды.

Моя компания производит AnthillPro , и мы работали с рядом компаний над крупными встраиваемыми проектами, а также надёжными проектами. IBM, вероятно, самый крупный игрок в мире с BuildForge.

AnthillPro делает дополнительный акцент на том, что вы делаете с изображениями в минутах / часах / днях после сборки (вы устанавливаете их на симуляторах / оборудовании и запускаете автоматизированные тесты? Ставите их? Продвигаете их?), Но мы также видим людей используя его только для сборки.

Answer 3

Стоимость не объект?Я работал на GreenHills, и они решили эти проблемы для своих собственных ферм сборки / тестирования.Попросите их сделать то же самое для вас.