ПИ
кажется теперь я понимаю, почему на собесах задают вопрос про разницу composer update и composer install
Size: a a a
2020 July 31
АГ
тут скорее не про ребят а про начальника речь)
АГ
Vlad Sobenko
Тоже так делали на прошлом проекте. Но ниразу не упало, удивительно))
что подтверждает идею о том, что если код хороший - то апдейты ничего не сломают) так и должно быть на любом нормальном проекте)
AM
привет всем. у нас тут возник спор в команде по поводу, держать vendor под контролем версий или нет? как считаете, в каком случае это делать можно / нужно?
боооооооооооооооооооооооже. Нужно только в том случае, если с репой будет работать только девочка из бухгалтерии, которой нужна копия готового сайта
ПИ
что подтверждает идею о том, что если код хороший - то апдейты ничего не сломают) так и должно быть на любом нормальном проекте)
могут сломать. не стоит так делать
AM
отвратные и жирные коммиты
проблемы конфликтов при мерджах до кучи
VS
что подтверждает идею о том, что если код хороший - то апдейты ничего не сломают) так и должно быть на любом нормальном проекте)
Не угадал. 3 джуна пилили свой первый проэкт с нуля. Иногда смотрели мидлы, били по рукам. Но не всегда.
A
Может пусть сначала докажут, зачем нужно держать под контролем версий?
Смысл держать под контролем - вендоринг. Т.е. у тебя всегда есть готовый продукт.
Если ты держишь только composer.lock и у тебя нет никаких внутренних систем, которые хранят кеш артефактов то возможен случай, когда ты не можешь собрать проект по причине упал гитхаб/упал пакаджист.
Если ты держишь только composer.lock и у тебя нет никаких внутренних систем, которые хранят кеш артефактов то возможен случай, когда ты не можешь собрать проект по причине упал гитхаб/упал пакаджист.
AM
вот тебе аргумент - похапэшники не далеко ушли от js-ников в плане релиза пакетов, и "иногда" случаются косяки аля тег удалили или коммит... или еще какую дич которая ломает lock файл. А еще бывает такое что репозиторий удаляют
Проще дублировать зависимости в своё хранилище, аля self hosted packagist.
VS
Смысл держать под контролем - вендоринг. Т.е. у тебя всегда есть готовый продукт.
Если ты держишь только composer.lock и у тебя нет никаких внутренних систем, которые хранят кеш артефактов то возможен случай, когда ты не можешь собрать проект по причине упал гитхаб/упал пакаджист.
Если ты держишь только composer.lock и у тебя нет никаких внутренних систем, которые хранят кеш артефактов то возможен случай, когда ты не можешь собрать проект по причине упал гитхаб/упал пакаджист.
Может лучше при пуше в мастер создавать артифакт с вендором? На чёрный день.
АГ
могут сломать. не стоит так делать
в таком случае стоит прибивать версии в composer.json более жестко
AD
в таком случае стоит прибивать версии в composer.json более жестко
Или запускать тесты в момент апдейта
ПИ
просто не надо апдейт делать в CI/CD вот и все :) руками обновил, проверил, запушил
VS
Или запускать тесты в момент апдейта
В таком случае должны быть идеальные тесты.
АГ
ну да, но вообще есть практика собирания кода внутрь докер контейнера, но в целом да, тесты в любом случае зпускаются когда уже весь проект собран и запущен
AM
в таком случае стоит прибивать версии в composer.json более жестко
как будто нет либ, нарушающих semver
AD
Vlad Sobenko
В таком случае должны быть идеальные тесты.
Волков боятся - в лес не ходить)
Тогда и composer update не запускать
Тогда и composer update не запускать
ПИ
ну да, но вообще есть практика собирания кода внутрь докер контейнера, но в целом да, тесты в любом случае зпускаются когда уже весь проект собран и запущен
смотря какие :) Для Unit не нужно запускать nginx, бд и так далее
АГ
а часто ли вы сталкивались с ситуацией, когда апдейт реально ломал систему? имеется ввиду, при этом, что версия не была прописана как "*"
VS
Волков боятся - в лес не ходить)
Тогда и composer update не запускать
Тогда и composer update не запускать
Хз. Мы делаем в рамках отдельного таска. Чтобы хоть потыкать немного, что ничего не отвалилось.