для тех когда тебе надо быстро вносить правки

подразумевается выкатка текущего билда на тестовый сервер, где он покрывается тестами автоматически, если все тесты прошли, он уходит на боевой сервак

как-то так

для тех когда тебе надо быстро вносить правки

скорее не "быстро", а "часто" ci - это автоматизация процесса релиза

Для каких случаев его юзают

самый большой профит в continious integration заключается в том что эффект "на моем компе все работает" минимизируется.

Спасибо большое

А тесты сами я пишу?

Потом при отправке автоматически запускаются тесты если ок то идет каммит в боевой сервер

А тесты сами я пишу?

можно настроить CI вообще без тестов

?

на самом деле профит от CI будет даже без тестов - можно запихнуть туда php-cs-fixer, php-md, компиляцию ассетов и еще что-нибудь

если говорить про симфу - линт ямла, твига, установку зависимостей

вот fixer наверное не надо

на CI только чеки делать

о_О

а чем чек кодстайла не чек?

а он чекать умеет?))

я думал только правит

--dry-run

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

норм

используем с dry-run и diff

отлично работает

сразу показывает при билде, где ошибки

Юзать кодингстайл значит

Окай

ну а дальше зависит от того, что умеет команда

умеете тесты - пишете тесты

Я одинокий самурай без команды)

тогда по любому юзай ci/cd :)

https://symfony-devs.slack.com/archives/support/p1483627899001281

Спасибо большое

Холи щит)

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

клиенты этого не видят, но чувствуют, что пайплайн выстроен

Я хотел бы заметить что CI это именно continues integration. Ни какой поставки кода в прод тут нету

Только интеграция изменений в продукт

Когда оно вжух и в продакшен это континиус деливери

> Когда оно вжух и в продакшен это континиус деливери справедливости ради тогда стоит заметить, что речь тогда идет о подходах а не о инструментах. Любой CI-сервер с поддержкой пайплайнов вполне себе годится и для CI и для CD

пайплайны)

самый простой это в баше set -e

не ну это да)

хотя мне больше нравится -ex что бы знать что там происходит

ну да

> Когда оно вжух и в продакшен это континиус деливери справедливости ради тогда стоит заметить, что речь тогда идет о подходах а не о инструментах. Любой CI-сервер с поддержкой пайплайнов вполне себе годится и для CI и для CD

да, но просто хотелось чуть-чуть позанудствовать

к вопросу о php и долгоживущих скриптах

пришлось запилить декоратор над entity manager-ом который бы пересоздавал оный в случае фэйла...

(

Ага)

пришлось запилить декоратор над entity manager-ом который бы пересоздавал оный в случае фэйла...

А при чём тут PHP?

А при чём тут PHP?

на днях просто обсуждали...

Ну это закрывающийся entity manager

Не проблему я понимаю

не совсем... это закрывающее-ся соединение и в целом это окъ

Вообще его под каждый запрос в идеале надо создавать заново

Просто это не проблема PHP =)

Вообще его под каждый запрос в идеале надо создавать заново

нууу... сам em не обязательно, только UoW чистить

нууу... сам em не обязательно, только UoW чистить

Ну он писал с расчетом на один единственный реквест, все же)

Ибо фигли он закрывается

Ну он писал с расчетом на один единственный реквест, все же)

ну и опять же тогда выходит что DoctrineBundle не предоставляет возможности "пересоздать" зависимость, нет доступа к фабрике (а может и есть....)

буду завтра уже ковыряться... вдруг реально можно фабрику выковырять

тогда все ништяк

Ну он писал с расчетом на один единственный реквест, все же)

Ну это же просто конкретная реализация

К слову там всё довольно просто можно подменить

Хотя в разреде doctrine bundle не уверен

Ну это же просто конкретная реализация

окей окей, ну тогда сведу задачу к "пока в php нельзя будет дебагер для запущеного процесса прицепить не ок"

ERROR: S client not available

окей окей, ну тогда сведу задачу к "пока в php нельзя будет дебагер для запущеного процесса прицепить не ок"

Хех =)

> К слову там всё довольно просто можно подменить да это не проблема... проблема в том что entity manager регистрируется как сервис, и в рантайме "подменить" его не выйдет..

и если он у тебя закрылся - он у тебя закрылся

и ничего ты с этим не сделаешь

Ну так он закрываеться из за ошибки

без тонны переписывания.... вот если доберусь до фабрики тогда все будет ок, но что-то мне подсказывает что "фабрика" там на уровне компайл пасов...

Ну так он закрываеться из за ошибки

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

По идее тебе нужно подменить только работу с коннектами

проблема что я не могу просто взять и организовать это без перелопачивания кучи всего

чисто для коннектов - там есть возможность класс-враппер задать

ну то есть есть кастылики удобные есть

Ну так тебе и надо просто коннект свой

Который будет следить за жизьню

Что бы база "не бегала" =)

дай поныть

)

Да уже 700 сообщений ноете =)

Я прочитал их, и не понял всех поинтов =)

тут никто не хочет поболтать на тему "фигачим в контроллерах"?

похоливарить за CQRS и ADR

Было бы интересно почитать тут, в чатике, о реализации подобных вещей из первых уст, так сказать ☺️

Кто как считает, у контроллеров вообще какие обязанности? Чисто как передатчик от data source к view? Или использовать внутри экшнов сервисы типа мапперов из одного представления объектов в другое это нормально?

Кто как считает, у контроллеров вообще какие обязанности? Чисто как передатчик от data source к view? Или использовать внутри экшнов сервисы типа мапперов из одного представления объектов в другое это нормально?

https://gist.github.com/fesor/98ff82ae9e58bcaa840f11d6e2d23652

вот мои упоротые мысли на этот счет

если конкретно по твоему вопросу - контроллеры это UI layer в контексте бэкэнда

"адаптер" поверх приложения

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

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

что мол если GRASP контроллеры старые добрые + некие респондеры

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

Кажется дошло. Просто раньше я как-то не задумывался на этот счёт. Фигачил SomethingRepositoryInterface в метод контроллера и отдавал коллекцию или json там. Сейчас, имея дело с более лёгким обвесом, начал задумываться больше об архитектуре и реализации некоторых штук, которых не хватает, врукопашную.

Более легкий обвес — это то ядро, о котором некогда говорили.

хз, для меня HttpKernel это легкий обвес