Отличный способ выполнить непрерывную интеграцию с Угловыми CLI и Jenkins

Question

Я пытаюсь настроить правильный способ выполнения непрерывной интеграции с Угловой CLI.

Просто для удовольствия я управляю своим Дженкинсом в Windows, и я создал тестовый проект с Угловой CLI.

Этот проект связан с удаленным Bitbucket, и я использую Sourcetree в качестве системы контроля версий.

Но у меня есть несколько вопросов о правильном рабочем процессе для применения, потому что я довольно смущен.

1) Угловая CLI позволяет нам построить проект с командой ng build. Он создает папку с именем dist. Хорошо, но эта папка игнорируется в .gitignore, почему? Я имею в виду, мне нужна эта папка, потому что это используется моей работой Jenkins для ее развертывания через FTP в моем домене, нет? Если папка проигнорирована, она не будет доступна в удаленной битбакете, поэтому непригодной для использования Дженкинсом.

2) Jenkins используется для выполнения некоторых задач развертывания. Его нельзя использовать для того, чтобы делать то же самое, что и ng build? На мой взгляд, concat, minification и т. Д. Должны интегрироваться в задание на работу, я прав? В соответствии с этим расщепляется задача «построить»?

Мне нужно уточнение. Это первый раз, когда я это делаю.

Благодарю вас.

Answer 1

1. сборник артефактов, сгенерированный код, скомпилированные классы ... и т. Д. NOT источник контролируется как лучшая практика. исходный код является вашим источником правды, поэтому все, что вы можете построить/препроцесс оттуда, игнорируется из источника управления. как правило, ваши задания в вашем конвейере сборки связывают ваше приложение/артефакты и развертывают его в каком-то хранилище для будущего использования или доставки или архивируют через Jenkins.

2. В Jenkins вы можете указать рабочие задания, которые можно вручную или автоматически запускать в зависимости от конфигурации. Я лично предпочитаю иметь базовое начальное задание сборки, которое запускается SCM с помощью сервисного крюка, когда есть push, который сначала создает артефакты/приложение, а также архивирует артефакты сборки в репозиторий артефактов. вы можете иметь задание доставки по потоку, которое может выполнять развертывание артефактов сборки, и здесь вы можете использовать несколько плагинов Jenkins для развертывания в зависимости от вашего варианта использования. Кстати, как только вы настраиваете отношения вверх/вниз по течению в заданиях построения, вы можете создать представление конвейера, выбрав начальное задание. он создает прекрасный вид на конвейер.

Я рекомендую вам также взглянуть на вопрос Jenkis downstream job fails to find upstream artifacts stackoverflow. Надеюсь, это ответит на ваш вопрос.

Answer 2

1) На самом деле не самая лучшая практика иметь папку dist под контролем источника. Папка dist содержит вывод вашего ng build, что означает каждый раз, когда вы запускаете ng build, содержимое папки dist меняется. Если вы столкнулись с этим под контролем источника, это приведет к регулярному слиянию конфликтов. Это цель сборки (любой сборки) для создания этой папки. Ваше задание CI также является сборкой, поэтому оно также создает папку dist.
Jenkins, в частности, имеет отдельную «рабочую область» для каждого заданного вами задания.При запуске вашего задания CI выполняется обновление рабочей области (в зависимости от вашей конфигурации и VCS). Затем свежие источники используются для запуска сборки, как и на вашей локальной машине. ng build очищает папку dist и создает новую.
К тому времени, когда сборка будет завершена, вы готовы развернуть папку dist любым способом, который вы сочтете подходящим (zip it -> отправить его по FTP/SSH -> inflate -> выполнить необходимые задачи, чтобы вещи были поданы через ваш HTTP-сервер).

2) Конкатенация, минимизация и комплектация должны выполняться вашей работой CI. К счастью, ng cli способен сделать все, что для вас. Запустите ng build --prod. Переключатель --prod включит мини-классификацию и компиляцию AOT, создав наименьшие возможные пакеты для вашего распространения.
. Хорошая идея - добавить шаг для gzip файлов .css и .js и настроить ваш HTTP-сервер для обслуживания gzipped-версий пакетов, если их спросят (Accept-Encoding: gzip). Для машины окна, это сделает работу:
cd dist FOR %%i IN (*.js) DO "C:\Program Files\7-Zip\7za.exe" a "%%~ni.js.gz" "%%i" FOR %%i IN (*.css) DO "C:\Program Files\7-Zip\7za.exe" a "%%~ni.css.gz" "%%i"

Как уже упоминалось в ответ @ burcakulug, в если у вас есть система управления артефактом на месте, вы должны рассмотреть вопрос о создании трубопровода работу Дженкинс. Одна работа по созданию, связыванию и архивированию вашего проекта, второе (нижестоящее) задание для развертывания.

Надеюсь, это поможет немного :).