Без воды о том, как за 10 минут сделать:
1.Проверяем ваш composer.json на серьезные и несерьезные ошибки, вроде неоптимального autoload
2.Проверяем ваш composer.lock на security уязвимости в пакетах
3.Проверяем вашу базу данных, что ничего не забыли
4.Проверяем ваши YAML файлы
5.Проверяем Coding Style по Symfony
Меня удивляет, почему многие не используют данный функционал в своих проектах, которые уже давно работают на проде. Туториал очень маленький, но зато все по делу. И я все же надеюсь, что вы сможете подчеркнуть себе что-нибудь из данного материала.
1)Проверяем ваш composer.json на серьезные и несерьезные ошибки, вроде неоптимального autoload:
2)Проверяем ваш composer.lock на уязвимости в пакетах:
В случае, если в базе данных будут обнаружены какие-то уязвимости с тем или иным пакетом, нам покажется вот такая картинка:
И в CI вернется статус, что программа была некорректно завершена, что поломает билд и привлечет внимание разработчика.
Подробнее о проекте — security.sensiolabs.org
База данных — security.sensiolabs.org/database
3)Проверяем вашу базу данных
4)Проверяем ваши YAML файлы
Устанавливаем matthiasnoback/symfony-config-test для тестирования наших YAML файлов в проекте:
5.Проверяем Coding Style по Symfony
Устанавливаем escapestudios/symfony2-coding-standard и squizlabs/php_codesniffer, далее делаем следующее:
В случае, если есть нарушения, мы получим примерно такую картину с полным описанием:
1.Проверяем ваш composer.json на серьезные и несерьезные ошибки, вроде неоптимального autoload
2.Проверяем ваш composer.lock на security уязвимости в пакетах
3.Проверяем вашу базу данных, что ничего не забыли
4.Проверяем ваши YAML файлы
5.Проверяем Coding Style по Symfony
Меня удивляет, почему многие не используют данный функционал в своих проектах, которые уже давно работают на проде. Туториал очень маленький, но зато все по делу. И я все же надеюсь, что вы сможете подчеркнуть себе что-нибудь из данного материала.
1)Проверяем ваш composer.json на серьезные и несерьезные ошибки, вроде неоптимального autoload:
./composer.phar validate --no-check-all --strict2)Проверяем ваш composer.lock на уязвимости в пакетах:
php vendor/bin/security-checker security:checkВ случае, если в базе данных будут обнаружены какие-то уязвимости с тем или иным пакетом, нам покажется вот такая картинка:
И в CI вернется статус, что программа была некорректно завершена, что поломает билд и привлечет внимание разработчика.
Подробнее о проекте — security.sensiolabs.org
База данных — security.sensiolabs.org/database
3)Проверяем вашу базу данных
php bin/console doctrine:schema:validate -e=prodСитуация:
Разработчик внес изменения в сущности. Но забыл создать миграцию, а мы ведь нормальные и используем миграции для того, чтобы менять что-то в базе на проде? А тут еще и тимлид пропустил, что нет миграции на новые изменения. Выполняйте эту команду после того, как накатили все миграции на базу данных. Команда проверит, что изменений в бд в соответствии с маппингом сущностей больше никаких не требуется, что дает 100% гарантии, что никто не забыт, ничего не забыто.
4)Проверяем ваши YAML файлы
Устанавливаем matthiasnoback/symfony-config-test для тестирования наших YAML файлов в проекте:
php bin/console lint:yaml app/config/php bin/console lint:yaml src/AppBundle/Resources/config/5.Проверяем Coding Style по Symfony
Устанавливаем escapestudios/symfony2-coding-standard и squizlabs/php_codesniffer, далее делаем следующее:
php vendor/bin/phpcs ./src -p --encoding=utf-8 --extensions=php --ignore=Tests --standard=./vendor/escapestudios/symfony2-coding-standard/Symfony2В случае, если есть нарушения, мы получим примерно такую картину с полным описанием:
Комментарии (5)
merk
22.01.2018 01:35До кучи можно добавить проверку чексумм вендоров — github.com/sensiolabs/checksums
iborzenkov
С кодстайлом лучше все-таки php-cs-fixer или даже оба (хотя после фиксера phpcs только длину строк ловит)
artem90
Фиксер, на мой взгляд, надо запускать руками разработчику, а не исправлять код в процессе проверок.
Мало ли что исправиться не так как положено.
Fesor
никто не говорит о фиксе в ходе проверок. На CI надо с
--dry-runзапускать, а разработчик может себе git hook какой сделать что бы не забывать.