Обязанности Build Script и Build Server

Мне нужны некоторые разъяснения относительно обязанностей скрипта сборки и сервера сборки.

Я прочитал несколько статей в сети о непрерывной интеграции и сборках. В том числе

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

Насколько я понимаю, исходя из моих исследований (и, пожалуйста, исправьте меня здесь, поскольку это то, о чем я спрашиваю), идеал должен быть следующим:

каждый проект имеет свой скрипт сборки
этот скрипт строит проект
этот скрипт гарантирует, что зависимости построены ранее

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

Однако обязанности сервера сборки:

проверить хранилище
вызвать сборку
триггерные тесты и другие инструменты QA
сделать артефакт доступным

Это может быть вызвано вручную, ночью или при изменении хранилища.

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

Можете ли вы уточнить цели и уточнить обязанности?

version-control continuous-integration builds

— Angelo.Hannes
источник

Насколько это хороший вопрос, и на него ответят (я отвечу позже, когда у меня будет время, и на него еще не ответили): вам действительно следует вернуться и получить разъяснения от своего консультанта. Путаница после разговора с кем-то, кто будет оценивать вашу производительность, - это рецепт катастрофы и признак того, что они не общаются с вами должным образом (или вы не слушаете активно, но это не так). Вот).

— Стивен Эверс

@ Angelo.Hannes Я думаю, что вы достигли всех основных моментов. Можете ли вы уточнить, что вас смущает?

— М. Дадли

@SteveEvers Ну, как только что прочитал некоторые введения в эту тему, я хотел сначала расширить свои знания по этому вопросу. Тогда я обязательно подниму эту тему снова. Поэтому я был бы очень признателен за ваш ответ.

— Angelo.Hannes

@ M.Dudley Как я уже сказал, я не уверен, какие обязанности куда идут. И является ли правильный путь сборки сценария для всего программного обеспечения.

— Angelo.Hannes

Эти вещи ортогональны:

Сценарий сборки - это механизм, который при вызове в только что извлеченном дереве исходных кодов дает полную сборку требуемых целей и зависимостей. Это может быть просто «сделать все», если у вас есть make-файл, или подходящий вызов MSBuild, Ant, Maven или Scons. Если у вас сложная иерархия зависимостей или связанных проектов, ваш «сценарий сборки» может быть файлом верхнего уровня, который по очереди вызывает каждый из них, проверяя успех на ходу.

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

Сборки сервер , или , вернее , сервер непрерывной интеграции , является механизмом автоматизации отвечает за планирование / запуск, мониторинг и отчетность по кассе -> сборка -> тест -> упаковка -> этап -> развертывания трубопровод. Вы можете использовать cron / Task Scheduler, если у вас нет ничего более сложного в руках, но сейчас есть много отличных инструментов, таких как Jenkins, Cruise Control, TeamCity и т. Д.

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

— JBRWilkinson
источник