только изменённый, на CI есть задачи проверки и всего кода

У нас похожая ситуация с проверкой кода. На каждый пулл риквест запускается задача на CI сервере на проверку стиля. Если есть нарушения, пулл риквест будет иметь статус failed и бот отпишет где и в каких местах проблемы.
Плюс написан свой линтер, который у разработчиков вызывается локально на pre-commit hook
Всё круто работает, иногда правда с легаси кодом проблемы бывают

О каком сервере?

раньше надо было думать ;)

и слава богу :)
на самом деле, тоже был удивлён, что так можно делать

ну библиотека ведь всё равно вместо нас их описывает ;) https://github.com/Symplify/ControllerAutowire/blob/master/src/DependencyInjection/Compiler/RegisterControllersPass.php#L40

в Laravel 5 такие контроллеры например из коробки идут.
суть в общем в том была, что так или иначе контроллеры описать придётся при такой схеме, а вот всё остальное уже «автовайриться» будет

В целом контейнер неплохой, идея конфигурации только изнутри мне тоже нравится, за это плюс.

Но как мне кажется, подойдёт для не очень больших проектов, расскажу почему.

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

class SomeController
{

    /**
     * @var SomeLogicService $service
     */
    private $service;
    
    public function __construct(SomeLogicService $service)
    {
        $this->service = $service;
    }
}

class SomeLogicService
{
    /**
     * @var AnotherLogicService $service
     */
    private $service;

    public function __construct(AnotherLogicService $service)
    {
        $this->service = $service;
    }
}

Без auto-wiring мне придётся все 50 классов описывать в контейнере, в том числе и контроллер. А это несколько неудобно.
С auto-wiring остаточно описать контроллер в контейнере.
Так это работает в Laravel и Symfony (по крайней мере я так это использую)

ну в общем-то с первого взгляда это должно работать, согласен.

а Вы никак дефолтные значения для каких-то параметров не устанавливаете?
и если от CI у меня приходит название базы, имя и пароль в переменных окружения, мне надо что-то в духе писать?

return [
    'apiToken' => 'jdf73jdhgj',

    // вложенные массивы тоже поддерживаются
    'database' => [
        'connection' => $_ENV['connection'],
        'user'           => $_ENV['user'],
        'password'   => $_ENV['password']
    ]
];

по поводу организации конфигураций.

мне очень нравится подход, сделанный в Laravel — использование dotenv.
в корне есть .env файл, где содержится конфигурация специфичная для сервера.
либо мы можем установить эти переменные в переменные-окружения самого сервера.

по-моему, довольно просто и очевидное решение

повторюсь, делаю это для своих проектов, они маленькие, на одном сервере в основном

языки в основном php, python, так что компиляция не нужна

в плане БД есть миграции, которые можно тоже запустить в deploy.sh

зависимости тянуться с помощью composer install для php, в git лежит composer.lock, так что версии зафиксированы и если ничего не изменилось то и ничего не устанавливается

как говорил, фермы серверов нет, для обновления и очистки кэша через скрипт обновляется fpm

Ну а на рабочих сложных проектах конечно CD есть

на собственных проектиках есть постоянно deploy.sh, который делает git pull, перезагружает php-fpm и ещё что-нибудь. Работаю и не обламываюсь :) а настраивать CD на маленьких проектах как мне кажется это лишний геморрой

вот честно, приходилось работь и общаться с архитекторами БД и представления они использовали в случаях:
— спрятать какие-то данные(колонки) из запрсов
— спрятать тяжелые запросы, например, при генерации отчета
— для некоторых таблиц заведомо было известно, что их структура будет меняться, причем часто. Там тоже добавляли вью

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

ок, что такое промышленные сервера БД?
И ответьте пожалуйста, почему представления это хорошо? Я спрашиваю абсолютно серьёзно, может я что-то упустил в познаниях БД.

Всё, что я могу сказать по представлениям — это вынос логики из кода в БД, так же как хранимые пооцедуры (если не ошибаюсь представления и реализовпны как хранимки), поэтому он должен быть обоснован

Мне авторитетнее в этом вопросе разработчик MySQL https://www.percona.com/blog/2007/08/12/mysql-view-as-performance-troublemaker/

просто довольно авторитетный человек
Просто то, что у вас — это классическая Active Record, сущность, которая знает как достать себя из БД и как себя сохранить
Не знаю зачем вы не стали использовать довольно устоявшийся термин

во многих фреймворках это называется Active Record. Такое же название использует и Фаулер в PoEAA

откуда у вас информация, что использование БД представлений — бэст практис?

вы сравниваете только своё решение и доктрину. это два разных полюса, чёрное и белое. а есть ещё серое.

https://github.com/analogueorm/analogue
https://github.com/j4mie/idiorm
https://github.com/jpfuentes2/php-activerecord

да и ещё много

как раз-таки модель/сущность, соответствующая какому-то домену, особенно сложному и имеет наличие множества связей.

опережая ваш ответ, что в большинстве сайтов такое не надо — так и ведь сущность (Entity) как таковая там не нужная, достаточно просто реализовать Table Data Gateway
http://martinfowler.com/eaaCatalog/tableDataGateway.html

покажите где я написал про ORM или доктрину, на них свет клином не сошёлся. я говорю в целом про решение связанное с работой с БД.

Речь о том чтобы упростить разработку обычных сайтов — не порталов и не соцсетей. Сайтов где не критична скорость и нет сотен таблиц в БД.

ну в таком случае ваше решение тоже не самое простое, зачем beforeSave, afterSave и тд?