Что такое «артефакт» в рамках Сontinuous Delivery PHP приложений?

Question

[kalya]

В одной из презентаций по Сontinuous Delivery для PHP приложений был такой слайд image.slidesharecdn.com/continuousdeliveryfinal-14... (вот ссылка на саму презентацию www.slideshare.net/loalf/one-commit-one-release-co... на котором последний шаг - "сгенерировать артифакт (zip файл)" в рамках процесса сборки. Далее этот артефакт (zip файл) заливается на S3 и потом инструментом для деплоя скачивается, например, на staging сервер и запускаются необходимые тесты для определения стабильности билда.

Отсюда у меня возник вопрос - что должно входить в этот zip файл в контексте php приложения (в частности symfony 2)? Должен ли это быть абсолютно весь проект, т.е:
- исходный код
- все необходимые вендоры
- уже сгененерированные ассеты
- подготовленный кеш
и тд?

либо только какая-то часть?

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

Answer 1

[Сергей Протько]

артефакт это все то что генерируется в процессе сборки. В частности у меня в проектах где нет Docker, образ которого и является артефактом, а применяется старый добрый tar.gz это делается так:

@echo Build artifacts
    tar --exclude=".git" \
        --exclude=".idea" \
        --exclude="*.iml" \
        --exclude=".vagrant" \
        --exclude="build" \
        --exclude="node_modules" \
        --exclude="devops" \
        --exclude="specs" \
        --exclude="app/cache" \
        --exclude="app/logs" \
        --exclude="parameters.yml" \
        --exclude="web/uploads" \
        --exclude="web/app_dev.php" \
        -zcf build/build.tgz .

Еще артефакты могут включать дополнительные вещи:
- результаты прогона тестов. полезно когда тесты фэйлятся что бы присылать на email разработчикам репорт
- покрытие кода тестами, в виде xml или/и html
- репорты статических анализаторов, вроде phpmd, phpcpd и т.д.

Comments

[kalya]

Спасибо за ответ, но пока не прояснилось до конца вся картина. Т.е. фактически в артефакте остается исходный код с конфигами. Что на счет вендоров, файлов композера? и как дальше работать с артефактом и какова его цель? насколько я понял - артефакт дает возможность не делать git pull, так как все необходимое уже есть в архиве. какие еще плюсы есть у данного подхода?

[Сергей Протько]

kalya: посмотрите список исключений, мы берем рабочий код и убираем все то что не нужно для его запуска (например app_dev.php на сервере уже не нужен, или кэши или .git). composer.json так же не надо, у вас уже должны быть установлены все вендоры и сгенерирован и autoload.php и bootstrap.php.cache.

По сути это билд. Он загружается на сервер, распаковывается, туда добавляется parameters.yml (или как альтернатива все параметры могут быть в параметрах окружения и разруливаться через ENV), и должен работать сразу после этого. Никаких дополнительных действий кроме cache:clear -e=prod и накатки миграций производиться не должны

[Сергей Протько]

kalya: вы поймите, ключевое тут "артефакт это любой результат сборки". Зачем вы делаете сборку решать вам. У меня это прогон тестов, сборка билда и его деплоймент. В этом случае артефакты это репорты и билд. В случае с докером допустим у меня собирается docker-контейнер, на нем прогоняются тесты и он пушится в репозиторий. По сути артефактом будет новая ревизия в репозитории докер имиджей, а не файл который можно заархивировать. Хотя репорты всеравно остаются.

[kalya]

> composer.json так же не надо, у вас уже должны быть установлены все вендоры и сгенерирован и autoload.php и bootstrap.php.cache

а каким образом содержимое артефакта интегрируется с уже готовыми компонентами (описанными выше)? как тогда должна быть организована структура проекта, скажем, на stage сервере? и в какой момент должны быть установлены все вендоры и остальные компоненты?

[Сергей Протько]

kalya: есть такая штука как continuous integration сервер, который выполняет сборку. Структура та же что и у вас локально, тут как хотите. Просто скопируйте директорию вашего проекта в другое место и она будет работать.

Для деплоймента можно использовать штуки вроде capifony.

[kalya]

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